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

[Kent Overstreet <kent.overstreet@linux.dev>]

On Wed, Mar 20, 2024 at 07:14:35PM +0000, Matthew Wilcox wrote:
> On Wed, Mar 20, 2024 at 03:07:38PM -0400, Kent Overstreet wrote:
> > On Wed, Mar 20, 2024 at 06:55:36PM +0000, Matthew Wilcox wrote:
> > > GFP_NOFAIL should still fail for allocations larger than KMALLOC_MAX_SIZE.
> > > Or should we interpret that as "die now"?  Or "go into an unkillable
> > > sleep"?  If the caller really has taken the opportunity to remove their
> > > error handling path, returning NULL will lead to a crash and a lot of
> > > beard stroking trying to understand why a GFP_NOFAIL allocation has
> > > returned NULL.  May as well BUG_ON(size > KMALLOC_MAX_SIZE) and give
> > > the developer a clear indication of what they did wrong.
> > 
> > Why do we even need KMALLOC_MAX_SIZE...?
> > 
> > Given that kmalloc internally switches to the page allocator when
> > needed, I would think that that's something we can do away with.
> 
> ... maybe check what I said before replying?
> 
> /*
>  * SLUB directly allocates requests fitting in to an order-1 page
>  * (PAGE_SIZE*2).  Larger requests are passed to the page allocator.
>  */
> #define KMALLOC_SHIFT_MAX       (MAX_PAGE_ORDER + PAGE_SHIFT)
> 
> You caan't allocate larger than that without going to CMA or some other
> custom allocator.

Ahh, my recollection was out of date - I believe that was 128k at one
time?