Re: [Lsf-pc] [LSF/MM/BPF TOPIC] Reclamation interactions with RCU

["NeilBrown" <neilb@suse.de>]

On Thu, 21 Mar 2024, Dan Carpenter wrote:
> On Mon, Mar 04, 2024 at 09:45:48AM +1100, NeilBrown wrote:
> > I have in mind a more explicit statement of how much waiting is
> > acceptable.
> > 
> > GFP_NOFAIL - wait indefinitely
> 
> Why not call it GFP_SMALL?  It wouldn't fail.  The size would have to be
> less than some limit.  If the size was too large, that would trigger a
> WARN_ON_ONCE().

I would be happy with GFP_SMALL.  It would never return NULL but might
block indefinitely.  It would (as you say) WARN (maybe ONCE) if the size
was considered "COSTLY" and would possibly BUG if the size exceeded
KMALLOC_MAX_SIZE. 

> 
> I obviously understand that this duplicates the information in the size
> parameter but the point is that GFP_SMALL allocations have been
> reviewed, updated, and don't have error handling code.

We are on the same page here.

> 
> We'd keep GFP_KERNEL which would keep the existing behavior.  (Which is
> that it can sleep and it can fail).  I think that maps to GFP_RETRY but
> GFP_RETRY is an uglier name.

Can it fail though?  I know it is allowed to, but does it happen?

I think I would prefer the normal approach for allocations that are (or
might be) too large for GFP_SMALL was to *not* risk triggering oom.
So I'd rather we didn't have GFP_KERNEL (which I think does have that
risk) and instead (maybe) GFP_LARGE which sleeps but will return NULL
when an OOM condition is looming.

So we only get OOM for GFP_SMALL allocations (because not failing
simplifies the code), and where it is explicitly requested - like for
user-space allocations and probably for file cache allocations.

But I think that keeping it simple and only adding GFP_SMALL as we have
discussed would be a big step in the right direction and we don't need
to complicate it with other ideas.

Thanks,
NeilBrown


> 
> People could still use __GFP_NOFAIL for larger allocations.
> 
> regards,
> dan carpenter
> 
> 
>