Message-ID: <20201203114748.GB17338@dhcp22.suse.cz>
Date:   Thu, 3 Dec 2020 12:47:48 +0100
From:   Michal Hocko <mhocko@...e.com>
To:     David Hildenbrand <david@...hat.com>
Cc:     Minchan Kim <minchan@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        LKML <linux-kernel@...r.kernel.org>,
        linux-mm <linux-mm@...ck.org>, hyesoo.yu@...sung.com,
        willy@...radead.org, iamjoonsoo.kim@....com, vbabka@...e.cz,
        surenb@...gle.com, pullip.cho@...sung.com, joaodias@...gle.com,
        hridya@...gle.com, sumit.semwal@...aro.org, john.stultz@...aro.org,
        Brian.Starkey@....com, linux-media@...r.kernel.org,
        devicetree@...r.kernel.org, robh@...nel.org,
        christian.koenig@....com, linaro-mm-sig@...ts.linaro.org
Subject: Re: [PATCH v2 2/4] mm: introduce cma_alloc_bulk API

On Thu 03-12-20 10:47:02, David Hildenbrand wrote:
> On 03.12.20 09:28, Michal Hocko wrote:
[...]
> > I think we should aim at easy and very highlevel behavior:
> > - GFP_NOWAIT - unsupported currently IIRC but something that something
> >   that should be possible to implement. Isolation is non blocking,
> >   migration could be skipped
> > - GFP_KERNEL - default behavior whatever that means
> > - GFP_NORETRY - opportunistic allocation as lightweight as we can get.
> >   Failures to be expected also for transient reasons.
> > - GFP_RETRY_MAYFAIL - try hard but not as hard as to trigger disruption
> >   (e.g. via oom killer).
> 
> I think we currently see demand for 3 modes for alloc_contig_range()
> 
> a) normal
> 
> As is. Try, but don't try too hard. E.g., drain LRU, drain PCP, retry a
> couple of times. Failures in some cases (short-term pinning, PCP races)
> are still possible and acceptable.
> 
> GFP_RETRY_MAYFAIL ?

normal shouldn't really require anybody to think about gfp flags hard.
That to most people really means GFP_KERNEL.

> E.g., "Allocations with this flag may fail, but only when there is
> genuinely little unused memory." - current description does not match at
> all. When allocating ranges things behave completely different.
> 
> 
> b) fast
> 
> Try, but fail fast. Leave optimizations that can improve the result to
> the caller. E.g., don't drain LRU, don't drain PCP, don't retry.
> Frequent failures are expected and acceptable.
> 
> __GFP_NORETRY ?
> 
> E.g., "The VM implementation will try only very lightweight memory
> direct reclaim to get some memory under memory pressure" - again, I
> think current description does not really match.

Agreed. As mentioned above this would be an opportunistic allocation
mode.

 
> c) hard
> 
> Try hard, E.g., temporarily disabling the PCP. Certainly not
> __GFP_NOFAIL, that would be highly dangerous. So no flags / GFP_KERNEL?

NOFAIL semantic is out of question. Should we have a mode to try harder
than the default? I dunno. Do we have users? I think RETRY_MAYFAIL is a
middle ground between the default and NORETRY which is just too easy to
fail. This is the case for the allocator as well. And from what I have
seen people are already using MAYFAIL in order to prevent oom killer so
this is a generally recognized pattern.

> > - __GFP_THIS_NODE - stick to a node without fallback
> > - we can support zone modifiers although there is no existing user.
> > - __GFP_NOWARN - obvious
> > 
> > And that is it. Or maybe I am seeing that oversimplified.
> > 
> 
> Again, I think most flags make sense for the migration target allocation
>  path and mainly deal with OOM situations and reclaim. For the migration
> path - which is specific to the alloc_contig_range() allocater - they
> don't really apply and create more confusion than they actually help - IMHO.

Migration is really an implementation detail of this interface. You
shouldn't be even thinking that there is a migration underneath not even
mention to actually trying to control it. But well, we might end up
disagreeing here. What actually matters is existing users of the
interface.

-- 
Michal Hocko
SUSE Labs

Powered by blists - more mailing lists