linux-kernel - Re: [tip: sched/core] sched: Fix performance regression introduced by mm

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: <ed287d2f-5b53-dffb-dec3-e5b28fa70a52@canonical.com>
Date:   Fri, 23 Jun 2023 00:35:29 -0700
From:   John Johansen <john.johansen@...onical.com>
To:     Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc:     Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        Swapnil Sapkal <Swapnil.Sapkal@....com>,
        Peter Zijlstra <peterz@...radead.org>,
        linux-kernel@...r.kernel.org, linux-tip-commits@...r.kernel.org,
        Aaron Lu <aaron.lu@...el.com>, x86@...nel.org,
        Andrew Morton <akpm@...ux-foundation.org>,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [tip: sched/core] sched: Fix performance regression introduced by
 mm_cid

On 6/22/23 23:37, Sebastian Andrzej Siewior wrote:
> On 2023-06-21 16:59:31 [-0700], John Johansen wrote:
>>> Which turned a per-cpu cache into a global memory pool protected by a spinlock. It may benefit RT, but it does not appear to be so great at scaling.
>>>
>> it is not. And I have a patch that needs some more formal testing for some stats.
>> Ubuntu pulled it in last cycle so it has gotten a fair bit of use and is looking good
>> on that end. There are probably some tweaks that can be done to improve it. The
>> backoff in particular is something that has mostly been adjusted in response to some
>> basic benchmarking.
>>
>> anyways patch below
>>
>> commit e057e9b47f1749882ea0efb4427d6b9671c761ab
> 
> I think I've been looking at this patch, or a former version of it, and
> it looked good.
> 
iirc the difference with the earlier version, is in the put case. Where in
the earlier version, if there was lock contention the buffer would always
get pushed onto the percpu list. With some debug patches on top we
saw some degenerate cases where this would result in percpu lists that
had excessive buffers on them.

So this version added a condition to force putting the buffer back
in to the global pool if the percpu list already has 2 buffers
cached on it.