[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b2a56713-a3e9-ea39-1fa1-663e9c6cdf2c@linux.alibaba.com>
Date: Tue, 14 Jun 2022 10:38:01 +0800
From: Rongwei Wang <rongwei.wang@...ux.alibaba.com>
To: Christoph Lameter <cl@...two.de>, penberg@...nel.org
Cc: David Rientjes <rientjes@...gle.com>, songmuchun@...edance.com,
Hyeonggon Yoo <42.hyeyoo@...il.com>, akpm@...ux-foundation.org,
vbabka@...e.cz, roman.gushchin@...ux.dev, iamjoonsoo.kim@....com,
linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/3] mm/slub: fix the race between validate_slab and
slab_free
On 6/13/22 9:50 PM, Christoph Lameter wrote:
> On Sat, 11 Jun 2022, Rongwei Wang wrote:
>
>>> Ok so the idea is to take the lock only if kmem_cache_debug. That looks
>>> ok. But it still adds a number of new branches etc to the free loop.
>>>
>>> Some performance tests would be useful.
>> Hi Christoph
>>
>> Thanks for your time!
>> Do you have some advice in benchmarks that need me to test? And I find that
>> hackbench and lkp was used frequently in mm/slub.c commits[1,2]. But I have no
>> idea how to use these two benchmarks test to cover the above changes. Can you
>> give some examples? Thanks very much!
>
>
> Hi Rongwei,
>
> Well run hackbench with an without the change.
OK
>
> There are also synthetic benchmarks available at
> https://gentwo.org/christoph/slub/tests/
That's great, thanks very much!
>
> These measure the cycles that slab operations take. However, they are a
> bit old and I think Pekka may have a newer version of these
> patches.
>
> Greetings,
> Christoph
Powered by blists - more mailing lists