On Tue, Feb 22, 2022 at 07:59:08PM +0000, Matthew Wilcox wrote: > On Tue, Feb 22, 2022 at 08:10:32AM +0000, Hyeonggon Yoo wrote: > > On Mon, Feb 21, 2022 at 03:53:39PM +0000, Matthew Wilcox wrote: > > > On Mon, Feb 21, 2022 at 10:53:34AM +0000, Hyeonggon Yoo wrote: > > > > SLAB's kfree() does not support freeing an object that is allocated from > > > > kmalloc_large(). Fix this as SLAB do not pass requests larger than > > > > KMALLOC_MAX_CACHE_SIZE directly to page allocator. > > > > > > I was wondering if we wanted to go in the other direction and get rid of > > > kmalloc cache sizes larger than, say, 64kB from the SLAB allocator. > > > > Good point. > > > > Hmm.. I don't think SLAB is benefiting from queueing that large objects, > > and maximum size is still limited to what buddy allocator supports. > > > > I'll try reducing kmalloc caches up to order-1 page like SLUB. > > That would be easier to maintain. > > If you have time to investigate these kinds of things, I think SLUB would > benefit from caching order-2 and order-3 slabs as well. Maybe not so much > now that Mel included order-2 and order-3 caching in the page allocator. > But it'd be interesting to have numbers. That's interesting topic. But I think this is slightly different topic. AFAIK It's rare that a workload would benefit more from using slab for large size objects (8K, 16K, ... etc) than using page allocator. And yeah, caching high order slabs may affect the numbers even if page allocator caches high order pages. SLUB already caches them and SLUB can cache more slabs by tuning number of cpu partial slabs (s->cpu_partial_slabs) and number of node partial slabs. (s->min_partial) I need to investigate what actually Mel did and learn how it affects SLUB. So it will take some time. Thanks! -- Hyeonggon
