On Wed, 7 Sep 2022 10:47:24 +0100 Mel Gorman <mgorman@xxxxxxxxxxxxxxxxxxx> wrote: > On Tue, Sep 06, 2022 at 09:35:41AM +0200, Michal Hocko wrote: > > > From: "NeilBrown" <neilb@xxxxxxx> > > > 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. Unclear what you mean by "rebased". You're saying the patch might have issues - doesn't that mean it needs to be "fixed"? Anyway, I've been maintaining this change for nearly a year - if nothing happens soon I guess I'll drop it so it doesn't get in people's way.
