[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5552D041-8549-4E76-B3EC-03C76C117077@oracle.com>
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.
Powered by blists - more mailing lists