Re: [RFC][PATCH 00/25]: Propagating GFP_NOFS inside __vmalloc()

[David Rientjes <rientjes@google.com>]

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@kvack.org.  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@kvack.org"> email@kvack.org </a>