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

Kent Overstreet
2024-03-20T19:33:23Z

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?