From: Mel Gorman <mgorman@techsingularity.net>
To: Michal Hocko <mhocko@suse.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
NeilBrown <neilb@suse.de>,
Thierry Reding <thierry.reding@gmail.com>,
Matthew Wilcox <willy@infradead.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Mel Gorman <mgorman@suse.de>, Vlastimil Babka <vbabka@suse.cz>
Subject: Re: [PATCH] MM: discard __GFP_ATOMIC
Date: Wed, 7 Sep 2022 10:47:24 +0100 [thread overview]
Message-ID: <20220907094724.5lanecgcjg75vxv3@techsingularity.net> (raw)
In-Reply-To: <Yxb4TQ0WDa85uurY@dhcp22.suse.cz>
On Tue, Sep 06, 2022 at 09:35:41AM +0200, Michal Hocko wrote:
> > From: "NeilBrown" <neilb@suse.de>
> > Subject: mm: discard __GFP_ATOMIC
> >
> > __GFP_ATOMIC serves little purpose. Its main effect is to set
> > ALLOC_HARDER which adds a few little boosts to increase the chance of an
> > allocation succeeding, one of which is to lower the water-mark at which it
> > will succeed.
> >
> > It is *always* paired with __GFP_HIGH which sets ALLOC_HIGH which also
> > adjusts this watermark. It is probable that other users of __GFP_HIGH
> > should benefit from the other little bonuses that __GFP_ATOMIC gets.
> >
> > __GFP_ATOMIC also gives a warning if used with __GFP_DIRECT_RECLAIM.
> > There is little point to this. We already get a might_sleep() warning if
> > __GFP_DIRECT_RECLAIM is set.
> >
> > __GFP_ATOMIC allows the "watermark_boost" to be side-stepped. It is
> > probable that testing ALLOC_HARDER is a better fit here.
> >
> > __GFP_ATOMIC is used by tegra-smmu.c to check if the allocation might
> > sleep. This should test __GFP_DIRECT_RECLAIM instead.
> >
> > This patch:
> > - removes __GFP_ATOMIC
> > - causes __GFP_HIGH to set ALLOC_HARDER unless __GFP_NOMEMALLOC is set
> > (as well as ALLOC_HIGH).
> > - makes other adjustments as suggested by the above.
> >
> > The net result is not change to GFP_ATOMIC allocations. Other
> > allocations that use __GFP_HIGH will benefit from a few different extra
> > privileges. This affects:
> > xen, dm, md, ntfs3
> > the vermillion frame buffer
> > hibernation
> > ksm
> > swap
> > all of which likely produce more benefit than cost if these selected
> > allocation are more likely to succeed quickly.
>
> This is a good summary of the current usage and existing issues. It also
> shows that the naming is tricky and allows people to make wrong calls
> (tegra-smmu.c). I also thing that it is wrong to couple memory reserves
> access to the reclaim constrains/expectations of the caller.
>
I think it's worth trying to get rid of __GFP_ATOMIC although this patch
needs to be rebased. Without rebasing it, I suspect there is a corner case
for reserving high order atomic blocks. A high-order atomic allocation
might get confused with a __GFP_HIGH high-order allocation that can sleep.
It would not be completely irrational to have such a caller if it was in a
path that can tolerate a stall but stalling might have visible consequences.
I'm also worried that the patch might allow __GFP_HIGH to ignore cpusets
which is probably not intended by direct users like ksm.
> > Link: https://lkml.kernel.org/r/163712397076.13692.4727608274002939094@noble.neil.brown.name
> > Signed-off-by: NeilBrown <neilb@suse.de>
> > Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org>
> > Cc: Michal Hocko <mhocko@suse.com>
> > Cc: Thierry Reding <thierry.reding@gmail.com>
> > Cc: Mel Gorman <mgorman@techsingularity.net>
> > Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>
> Yes, I am all for dropping the gfp flag. One thing that is not really
> entirely clear to me, though, is whether we still need 3 levels of
> memory reserves access. Can we just drop ALLOC_HARDER? With this patch
> applied it serves RT tasks and conflates it with __GFP_HIGH users
> essentially. So why do we need that additional level of reserves?
I think this would fall under the "naming is hard". If __GFP_ATOMIC was
removed, the ALLOC_ flags might need renaming to detect differences in
high priority allocations (RT + GFP_ATOMIC), critical allocations (OOM)
and ones that can access special reserves (GFP_ATOMIC high-order).
--
Mel Gorman
SUSE Labs
next prev parent reply other threads:[~2022-09-07 9:47 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-17 4:39 [PATCH] MM: discard __GFP_ATOMIC NeilBrown
2021-11-17 13:18 ` Matthew Wilcox
2021-11-18 23:14 ` NeilBrown
2021-11-19 14:10 ` Matthew Wilcox
2021-11-20 10:51 ` NeilBrown
2021-11-22 16:54 ` Michal Hocko
2021-11-23 4:15 ` NeilBrown
2021-11-23 14:27 ` Michal Hocko
2021-11-18 9:22 ` Michal Hocko
2021-11-18 13:27 ` Mel Gorman
2021-11-18 23:02 ` NeilBrown
2021-11-22 16:43 ` Michal Hocko
2021-11-23 4:33 ` NeilBrown
2021-11-23 13:41 ` Michal Hocko
2022-04-30 18:30 ` Andrew Morton
2022-05-01 15:45 ` Michal Hocko
2022-09-06 7:35 ` Michal Hocko
2022-09-07 9:47 ` Mel Gorman [this message]
2022-10-17 2:38 ` Andrew Morton
2022-10-18 12:11 ` Mel Gorman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220907094724.5lanecgcjg75vxv3@techsingularity.net \
--to=mgorman@techsingularity.net \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mhocko@suse.com \
--cc=neilb@suse.de \
--cc=thierry.reding@gmail.com \
--cc=vbabka@suse.cz \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).