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

[Anand Mitra <anand.mitra@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1721 bytes --]

On Fri, Mar 11, 2011 at 1:01 PM, David Rientjes <rientjes@google.com> wrote:
>
>
> You're going to run into trouble by hard-wiring __GFP_REPEAT into all of
> the pte allocations because if GFP_NOFS is used then direct reclaim will
> usually fail (see the comment for do_try_to_free_pages(): If the caller is
> !__GFP_FS then the probability of a failure is reasonably high) and, if
> it does so continuously, then the page allocator will loop forever.  This
> bit should probably be moved a level higher in your architecture changes
> to the caller passing GFP_KERNEL.
>

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

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 ?

regards
-- 
Anand Mitra

[-- Attachment #2: Type: text/html, Size: 2346 bytes --]