Re: [PATCH RFC] mm: allow __GFP_NOFAIL allocation up to BLK_MAX_BLOCK_SIZE to support LBS

[Shakeel Butt <shakeel.butt@linux.dev>]

On Mon, Nov 03, 2025 at 10:01:54AM +0100, Vlastimil Babka wrote:
> On 11/3/25 08:55, Michal Hocko wrote:
> > On Fri 31-10-25 16:55:44, Matthew Wilcox wrote:
> >> On Fri, Oct 31, 2025 at 09:46:17AM -0700, Shakeel Butt wrote:
> >> > Now for the interface to allow NOFS+NOFAIL+higher_order, I think a new
> >> > (FS specific) gfp is fine but will require some maintenance to avoid
> >> > abuse.
> >> 
> >> I don't think a new GFP flag is the answer.  GFP_TRUST_ME_BRO just
> >> doesn't feel right.
> > 
> > Yeah, as usual a new gfp flag seems convenient except history has taught 
> > us this rarely works.

Point taken and let me discuss below if any interface for such
allocation requeat makes sense or not.

> > 
> >> > I am more interested in how to codify "you can reclaim one I've already
> >> > allocated". I have a different scenario where network stack keep
> >> > stealing memory from direct reclaimers and keeping them in reclaim for
> >> > long time. If we have some mechanism to allow reclaimers to get the
> >> > memory they have reclaimed (at least for some cases), I think that can
> >> > be used in both cases.
> >> 
> >> The only thing that comes to mind is putting pages freed by reclaim on
> >> a list in task_struct instead of sending them back to the allocator.
> >> Then the task can allocate from there and free up anything else it's
> >> reclaimed at some later point.  I don't think this is a good idea,
> >> but it's the only idea that comes to mind.
> > 
> > I have played with that idea years ago. Mostly to deal with direct
> > reclaim unfairness when some reclaimers were doing a lot of work on
> > behalf of everybody else. IIRC I have hit into different problems, like
> > reclaim throttling and over-reclaim.
> 
> Btw, meanwhile we got this implemented in compaction, see
> compaction_capture(). As the hook is in __free_one_page() it should now be
> straightforward to arm it also for direct reclaim of e.g. __GFP_NOFAIL
> costly order allocations. It probably wouldn't make sense for non-costly
> orders because they are freed to the pcplists and we wouldn't want to make
> those more expensive by adding the hook there too.
> 
> It's likely the hook in compaction already helps such allocations. But if
> you expect the order-4 pages reclaim to be common thanks to the large
> blocks, it could maybe help if capture was done in reclaim too.

Thanks for the pointer, I didn't know about this mechanism. I think we
can expand the scope of this mechanism to whole __alloc_pages_slowpath()
which calls both reclaim and compaction. Currently free hook is only
triggered when compaction causes free but with larger scope reclaim can
trigger it as well. Now there are couple of open questions:

1. Should we differentiate and prioritize between different allocators?
   That is allocators with NOFS+NOFAIL get preference as they might be
   holding locks and might be impacting concurrent allocators or maybe
   prefer allocators which will release memory in near future.

2. At the moment, we do expect allocators in slow path to work for the
   betterment of the whole system. So, should we use this mechanism in
   not the first (or couple of) iterations of slowpath but during later
   iterations.

3. This mechanism still does not capture "reclaim from me" which was
   Willy's original point. "Reclaim from me" seems more involved as I
   can see reclaim in general prefers to reclaim cold memory. In
   addition there are memcg protections (low/min). So, reclaim
   algo/heuristics may decide you are not reclaimable. Not sure if it is
   still worth trying the "reclaim from me" option.

Anyways at the moment I think if we go with this mechanism, we might
really need an explicit interface. We may in future if we try to be more
fancy.

thanks,
Shakeel