lkml.org 
[lkml]   [2015]   [Nov]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 1/3] tree wide: get rid of __GFP_REPEAT for order-0 allocations part I
From
Date
On 11/27/2015 10:38 AM, Michal Hocko wrote:
> On Wed 18-11-15 15:15:29, Vlastimil Babka wrote:
>
> I am not sure whether we found any conclusion here. Are there any strong
> arguments against patch 1? I think that should be relatively
> non-controversial.

Agreed.

> What about patch 2? I think it should be ok as well
> as we are basically removing the flag which has never had any effect.

Right.

> I would like to proceed with this further by going through remaining users.
> Most of them depend on a variable size and I am not familiar with the
> code so I will talk to maintainer to find out reasoning behind using the
> flag. Once we have reasonable number of them I would like to go on and
> rename the flag to __GFP_BEST_AFFORD and make it independent on the
> order. It would still trigger OOM killer where applicable but wouldn't
> retry endlessly.
>
> Does this sound like a reasonable plan?

I think we should consider all the related flags together before
starting renaming them. So IIUC the current state is:

~__GFP_DIRECT_RECLAIM - no reclaim/compaction, fails regardless of
order; good for allocations that prefer their fallback to the latency of
reclaim/compaction

__GFP_NORETRY - only one reclaim and two compaction attempts, then fails
regardless of order; some tradeoff between allocation latency and fallback?

__GFP_REPEAT - for costly orders, tries harder to reclaim before oom,
otherwise no difference - doesn't fail for non-costly orders, although
comment says it could.

__GFP_NOFAIL - cannot fail

So the issue I see with simply renaming __GFP_REPEAT to
__GFP_BEST_AFFORD and making it possible to fail for low orders, is that
it will conflate the new failure possibility with the existing "try
harder to reclaim before oom". As I mentioned before, "trying harder"
could be also extended to mean something for compaction, but that would
further muddle the meaning of the flag. Maybe the cleanest solution
would be to have separate flags for "possible to fail" (let's say
__GFP_MAYFAIL for now) and "try harder" (e.g. __GFP_TRY_HARDER)? And
introduce two new higher-level "flags" of a GFP_* kind, that callers
would use instead of GFP_KERNEL, where one would mean
GFP_KERNEL|__GFP_MAYFAIL and the other
GFP_KERNEL|__GFP_TRY_HARDER|__GFP_MAYFAIL.

The second thing to consider, is __GFP_NORETRY useful? The latency
savings are quite vague. Maybe we could just remove this flag to make
space for __GFP_MAYFAIL?


\
 
 \ /
  Last update: 2015-11-30 18:21    [W:0.056 / U:0.740 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site