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

[Michal Hocko <mhocko@suse.com>]

On Tue 04-11-25 13:32:52, Vlastimil Babka wrote:
> On 11/4/25 11:31 AM, Michal Hocko wrote:
> > On Mon 03-11-25 10:25:40, Michal Hocko wrote:
> >> On Mon 03-11-25 10:01:54, Vlastimil Babka wrote:
> >>> Maybe we could keep the warning for >=PMD_ORDER as that would still mean
> >>> someone made an error?
> >>
> >> I am not sure TBH. For those large requests (anything that is costly
> >> order) it is essentially a loop around allocator inside the allocator.
> >> I would be really much more worried about order-3 which still triggers
> >> the oom killer and could kill half of the system without much progress.
> >> For oder-2 you at least have task_struct which spans 2 pages but I do
> >> not think we have any guaranteed order-3 page for each task to guarantee
> >> anything when killing those.
> > 
> > Essentially something like this
> > diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> > index 25923cfec9c6..2df477d97cee 100644
> > --- a/mm/oom_kill.c
> > +++ b/mm/oom_kill.c
> > @@ -1142,6 +1142,14 @@ bool out_of_memory(struct oom_control *oc)
> >  	if (!(oc->gfp_mask & __GFP_FS) && !is_memcg_oom(oc))
> >  		return true;
> >  
> > +	/*
> > +	 * unlike for other !costly requests killing a task is not
> > +	 * really guaranteed to free any order-3 pages. Warn about
> > +	 * that to see whether that happens often enough to special
> > +	 * case.
> > +	 */
> > +	WARN_ON(oc->order == 3 && (oc->gfp_mask & __GFP_NOFAIL));
> 
> OK, it might not create an order-3 page immediately. But I'd expect it
> allows compaction to make progress thanks to making more free memory
> available? We do retry reclaim/compaction after OOM killing one process,
> and don't just kill until we succeed allocating, right?

Yes we do go through the reclaim/compaction cycle. Do you think this
warning is overzealous? Th idea is that a flood of OOMs could be easier
to pin point with this in place. It doesn't have to be full WARN_ON,
maybe pr_warn would be sufficient as the backtrace is usually printed 
in the oom report.
-- 
Michal Hocko
SUSE Labs