Re: cgroups: warning for metadata allocation with GFP_NOFAIL (was Re: folio_alloc_buffers() doing allocations > order 1 with GFP_NOFAIL)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Nov 13, 2023 at 10:48:39PM +0000, Matthew Wilcox wrote:
> On Mon, Nov 13, 2023 at 11:48:57AM -0800, Christoph Lameter wrote:
> > On Fri, 10 Nov 2023, Matthew Wilcox wrote:
> > 
> > > > Maybe Christoph is playing with min_slab_order or something, so we're
> > > > getting 8 pages per slab.  That's still only 2496 bytes.  Why are we
> > > > calling into the large kmalloc path?  What's really going on here?
> > > 
> > > Christoph?
> > 
> > Sorry I thought I already answered that.
> > 
> > This was a boot with slub_min_order=5 that was inadvertently left in from a
> > performance test.
> 
> Ah.  So do you think we need to fix this?

I'd leave the fix, so that we don't have to look into this "problem" next time.
But I'm not inclined to work on a proper fix: fixing the slab accounting
for this non-trivial setup. Maybe we should add a note into a doc saying that
raising slub_min_order might affect the slab accounting precision?




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]     [Monitors]

  Powered by Linux