Re: [PATCH] mm/slub: serve slabobj_ext array from a strictly larger kmalloc cache

From: Harry Yoo

Date: Wed Jul 01 2026 - 06:33:19 EST



On 7/1/26 5:43 PM, Harry Yoo wrote:
> On 7/1/26 4:42 PM, Harry Yoo wrote:
>> On 7/1/26 1:53 PM, Harry Yoo wrote:
>>> On 7/1/26 1:30 PM, Harry Yoo wrote:
>>>> We can do that in pre-7.2 kernels, by teaching kmalloc_type() and
>>>> kmalloc_slab() select the new KMALLOC_TYPE based on __GFP_NO_OBJ_EXT?
>>>>
>>>> e.g.) Select the new KMALLOC_TYPE when KMALLOC_NOT_NORMAL_BITS is not
>>>> set AND __GFP_NO_OBJ_EXT is set.
>>>
>>> Uh, this is bit subtle though.
>>>
>>> In some cases KMALLOC_DMA == KMALLOC_NORMAL,
>>> KMALLOC_CGROUP == KMALLOC_NORMAL,
>>> or KMALLOC_RECLAIM == KMALLOC_NORMAL.
>>>
>>> Just checking KMALLOC_NOT_NORMAL_BITS is misleading.
>>
>> Here's a prototype for slab/for-next. Backporting it requires handling
>> __GFP_NO_OBJ_EXT instead of SLAB_ALLOC_NO_RECURSE, but shouldn't be
>> too difficult. Now writing changelog and going through testing...
>
> Now thinking about the performance implication of sheaf allocations
> for kmalloc caches being served from KMALLOC_NO_RECURSE caches won't
> have sheaves at all

Oh, wait. I tried too hard to not introduce a new alloc_flag because
we cannot add new gfp flags when backporting it.

Probably it's just fine to simply reuse __GFP_NO_OBJ_EXT (because only
few caches have sheaves in v6.18) to select KMALLOC_NO_RECURSE,
while 7.2 can introduce a new flag.

--
Cheers,
Harry / Hyeonggon