linux-kernel - Re: [PATCH] slub: limit number of slabs to scan in count

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Sat, 13 Apr 2024 01:17:05 +0000
From: Jianfeng Wang <jianfeng.w.wang@...cle.com>
To: Vlastimil Babka <vbabka@...e.cz>,
        "Christoph Lameter (Ampere)"
	<cl@...ux.com>
CC: "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>,
        "penberg@...nel.org" <penberg@...nel.org>,
        "rientjes@...gle.com" <rientjes@...gle.com>,
        "iamjoonsoo.kim@....com"
	<iamjoonsoo.kim@....com>,
        "akpm@...ux-foundation.org"
	<akpm@...ux-foundation.org>,
        Junxiao Bi <junxiao.bi@...cle.com>
Subject: Re: [PATCH] slub: limit number of slabs to scan in count_partial()


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