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
