Re: [PATCH] slub: limit number of slabs to scan in count_partial()

From: Jianfeng Wang
Date: Fri Apr 12 2024 - 21:20:50 EST



> On Apr 12, 2024, at 1:44 PM, Jianfeng Wang <jianfeng.w.wang@xxxxxxxxxx> wrote:
>
> On 4/12/24 1:20 PM, Vlastimil Babka wrote:
>> On 4/12/24 7:29 PM, Jianfeng Wang wrote:
>>>
>>>
>>> On 4/12/24 12:48 AM, Vlastimil Babka wrote:
>>>> On 4/11/24 7:02 PM, Christoph Lameter (Ampere) wrote:
>>>>> On Thu, 11 Apr 2024, Jianfeng Wang wrote:
>>>>>
>>>>>> So, the fix is to limit the number of slabs to scan in
>>>>>> count_partial(), and output an approximated result if the list is too
>>>>>> long. Default to 10000 which should be enough for most sane cases.
>>>>>
>>>>>
>>>>> That is a creative approach. The problem though is that objects on the
>>>>> partial lists are kind of sorted. The partial slabs with only a few
>>>>> objects available are at the start of the list so that allocations cause
>>>>> them to be removed from the partial list fast. Full slabs do not need to
>>>>> be tracked on any list.
>>>>>
>>>>> The partial slabs with few objects are put at the end of the partial list
>>>>> in the hope that the few objects remaining will also be freed which would
>>>>> allow the freeing of the slab folio.
>>>>>
>>>>> So the object density may be higher at the beginning of the list.
>>>>>
>>>>> kmem_cache_shrink() will explicitly sort the partial lists to put the
>>>>> partial pages in that order.
>>>>>

Realized that I’d do "echo 1 > /sys/kernel/slab/dentry/shrink” to sort the list explicitly.
After that, the numbers become:
N = 10000 -> diff = 7.1 %
N = 20000 -> diff = 5.7 %
N = 25000 -> diff = 5.4 %
So, expecting ~5-7% difference after shrinking.

>>>>> Can you run some tests showing the difference between the estimation and
>>>>> the real count?
>>>
>>> Yes.
>>> On a server with one NUMA node, I create a case that uses many dentry objects.
>>
>> Could you describe in more detail how do you make dentry cache to grow such
>> a large partial slabs list? Thanks.
>>
>
> I utilized the fact that creating a folder will create a new dentry object;
> deleting a folder will delete all its sub-folder's dentry objects.
>
> Then, I started to create N folders, while each folder has M empty sub-folders.
> Assuming that these operations would consume a large number of dentry
> objects in the sequential order. Their slabs were very likely to be full slabs.
> After all folders were created, I deleted a subset of the N folders (i.e.,
> one out of every two folders). This would create many holes, which turned a
> subset of full slabs into partial slabs.