linux-kernel - Re: [PATCH 1/3] mm/slub: directly load freelist from cpu partial slab in the likely case

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <76641777-1918-2b29-b6aa-bda9b5467aa3@gentwo.org>
Date: Wed, 17 Jan 2024 14:41:13 -0800 (PST)
From: "Christoph Lameter (Ampere)" <cl@...two.org>
To: Chengming Zhou <zhouchengming@...edance.com>
cc: Hyeonggon Yoo <42.hyeyoo@...il.com>, Joonsoo Kim <iamjoonsoo.kim@....com>, 
    Vlastimil Babka <vbabka@...e.cz>, Pekka Enberg <penberg@...nel.org>, 
    Andrew Morton <akpm@...ux-foundation.org>, 
    Roman Gushchin <roman.gushchin@...ux.dev>, 
    David Rientjes <rientjes@...gle.com>, linux-mm@...ck.org, 
    linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/3] mm/slub: directly load freelist from cpu partial
 slab in the likely case

On Wed, 17 Jan 2024, Chengming Zhou wrote:

> The likely case is that we get a usable slab from the cpu partial list,
> we can directly load freelist from it and return back, instead of going
> the other way that need more work, like reenable interrupt and recheck.

Ok I see that it could be useful to avoid the unlock_irq/lock_irq sequence 
in the partial cpu handling.

> But we need to remove the "VM_BUG_ON(!new.frozen)" in get_freelist()
> for reusing it, since cpu partial slab is not frozen. It seems
> acceptable since it's only for debug purpose.

This is test for verification that the newly acquired slab is actually in 
frozen status. If that test is no longer necessary then this is a bug that 
may need to be fixed independently. Maybe this test is now required to be 
different depending on where the partial slab originated from? Check only 
necessary when taken from the per node partials?

> There is some small performance improvement too, which shows by:
> perf bench sched messaging -g 5 -t -l 100000
>
>            mm-stable   slub-optimize
> Total time      7.473    7.209

Hmm... Good avoiding the lock/relock sequence helps.