On Fri, 11 Mar 2011, Anand Mitra wrote: > I'll repeat my understanding of the scenario you have pointed out to > make sure we have understood you correctly. > > On the broad level the changes will cause a __GFP_NOFS flag to be > present in pte allocation which were earlier absent. The impact of > this is serious when both __GFP_REPEAT and __GFP_NOFS is set because > > 1) __GFP_NOFS will result in very few pages being reclaimed (can't go > to the filesystems) > 2) __GFP_REPEAT will cause both the reclaim and allocation to retry > more aggressively if not indefinitely based on the influence the > flag in functions should_alloc_retry & should_continue_reclaim > Yes, __GFP_REPEAT will loop in the page allocator forever if no pages can be reclaimed, probably as the result of being !__GFP_FS -- the oom killer also won't kill any processes to free memory because it requires __GFP_FS (to ensure we don't kill something unnecessarily just because this allocation is !__GFP_FS and direct reclaim has a high liklihood of failure). > Effectively we need memory for use by the filesystem but we can't go > back to the filesystem to claim it. Without the suggested patch we > would actually try to claim space from the filesystem which would work > most of the times but would deadlock occasionally. With the suggested > patch as you have pointed out we can possibly get into a low memory > hang. I am not sure there is a way out of this, should this be > considered as genuinely low memory condition out of which the system > might or might not crawl out of ? > As suggested in my email, I think you should pass "GFP_KERNEL | __GFP_REPEAT" into the lower level functions in this patchset instead of just GFP_KERNEL and not hard-wire __GFP_REPEAT into the lower level functions. GFP_NOFS | __GFP_REPEAT is a very risky combination that shouldn't be used anywhere in the kernel because it risks infinitely looping in the page allocator when memory is low. The callers passing only GFP_NOFS should handle the possiblity of returning NULL appropraitely. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>