On Wed, 2 Oct 2019, Michal Hocko wrote:
> > > If
> > > hugetlb wants to stress this to the fullest extent possible, it already
> > > appropriately uses __GFP_RETRY_MAYFAIL.
> >
> > Which doesn't work anymore right now, and should again after this patch.
>
> I didn't get to fully digest the patch Vlastimil is proposing. (Ab)using
> __GFP_NORETRY is quite subtle but it is already in place with some
> explanation and a reference to THPs. So while I am not really happy it
> is at least something you can reason about.
>
It's a no-op:
/* Do not loop if specifically requested */
if (gfp_mask & __GFP_NORETRY)
goto nopage;
/*
* Do not retry costly high order allocations unless they are
* __GFP_RETRY_MAYFAIL
*/
if (costly_order && !(gfp_mask & __GFP_RETRY_MAYFAIL))
goto nopage;
So I'm not sure we should spend too much time discussing a hunk of a patch
that doesn't do anything.
> b39d0ee2632d ("mm, page_alloc: avoid expensive reclaim when compaction
> may not succeed") on the other hand has added a much more wider change
> which has clearly broken hugetlb and any __GFP_RETRY_MAYFAIL user of
> pageblock_order sized allocations. And that is much worse and something
> I was pointing at during the review and those concerns were never really
> addressed before merging.
>
> In any case this is something to be fixed ASAP. Do you have any better
> proposa? I do not assume you would be proposing yet another revert.
I thought Mike Kravetz said[*] that hugetlb was not negatively affected by
this? We could certainly disregard this logic for __GFP_RETRY_MAYFAIL if
anybody is relying on excessive reclaim ("swap storms") that does not
allow compaction to make forward progress for some reason.
[*] https://marc.info/?l=linux-kernel&m=156771690024533
If not, for the purposes of this conversation we can disregard
__GFP_NORETRY per the above because thp does not use __GFP_RETRY_MAYFAIL.
