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

[Jianfeng Wang <jianfeng.w.wang@oracle.com>]

> On Apr 12, 2024, at 1:44 PM, Jianfeng Wang <jianfeng.w.wang@oracle.com> 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.