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

[Vlastimil Babka <vbabka@suse.cz>]

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?

> +
>  	/*
>  	 * Check if there were limitations on the allocation (only relevant for
>  	 * NUMA and memcg) that may require different handling.
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index d1d037f97c5f..ca8795156b14 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -3993,6 +3993,7 @@ __alloc_pages_may_oom(gfp_t gfp_mask, unsigned int order,
>  	/* Coredumps can quickly deplete all memory reserves */
>  	if (current->flags & PF_DUMPCORE)
>  		goto out;
> +
>  	/* The OOM killer will not help higher order allocs */
>  	if (order > PAGE_ALLOC_COSTLY_ORDER)
>  		goto out;
> @@ -4612,11 +4613,6 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order,
>  	int reserve_flags;
>  
>  	if (unlikely(nofail)) {
> -		/*
> -		 * We most definitely don't want callers attempting to
> -		 * allocate greater than order-1 page units with __GFP_NOFAIL.
> -		 */
> -		WARN_ON_ONCE(order > 1);
>  		/*
>  		 * Also we don't support __GFP_NOFAIL without __GFP_DIRECT_RECLAIM,
>  		 * otherwise, we may result in lockup.