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

[Dan Carpenter <dan.carpenter@linaro.org>]

On Mon, Mar 25, 2024 at 09:31:53AM +1100, NeilBrown wrote:
> On Fri, 22 Mar 2024, Dan Carpenter wrote:
> > On Fri, Mar 22, 2024 at 12:47:42PM +1100, NeilBrown wrote:
> > > 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'd like to keep GFP_SMALL much smaller than KMALLOC_MAX_SIZE.  IIf
> > you're allocating larger than that, you'd still be able to GFP_NOFAIL.
> > I looked quickly an I think over 60% of allocations are just sizeof(*p)
> > and probably 90% are under 4k.
> 
> What do you mean exactly by "keep"??

Poor word choice...

> Do you mean WARN_ON if it is "too big" - certainly agree.
> Do you mean BUG_ON if it is "too big" - maybe agree.

WARN_ON_ONCE().  But a lot of people have reboot on Oops enabled so
triggering a WARN_ON() is still a very serious bug.

> Do you mean return NULL if it is "too big" - definitely disagree.

Yeah.  It's going to be a style violation to check a GFP_SMALL
allocation for NULL so it needs to have GFP_NOFAIL behavior.  It can
still fail if it's larger than KMALLOC_MAX_SIZE.

> Do you mean build failure if it could be too big - I would LOVE that,
> but I don't think we can do that with current build tools.

The limit is going to be a constant so using static analysis to check
that is easier than checking if we're less than some variable.

regards,
dan carpenter