linux-kernel - Re: [patch 00/19] sched: Rewrite MM CID management

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: <877bwu0zte.ffs@tglx>
Date: Fri, 17 Oct 2025 09:09:33 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: LKML <linux-kernel@...r.kernel.org>
Cc: Peter Zijlstra <peterz@...radead.org>, Gabriele Monaco
 <gmonaco@...hat.com>, Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
 Michael Jeanson <mjeanson@...icios.com>, Jens Axboe <axboe@...nel.dk>,
 "Paul E. McKenney" <paulmck@...nel.org>, "Gautham R. Shenoy"
 <gautham.shenoy@....com>, Florian Weimer <fweimer@...hat.com>, Tim Chen
 <tim.c.chen@...el.com>, TCMalloc Team <tcmalloc-eng@...gle.com>
Subject: Re: [patch 00/19] sched: Rewrite MM CID management

On Wed, Oct 15 2025 at 19:29, Thomas Gleixner wrote:
>    Thread create teardown
>
>      I wrote a micro benchmark, which spawns pools which each create
>      threads and let the threads die after creation. The 32 pools/ 32
>      threads case triggers the ownership mode change case in both
>      directions. The source is appended at the end of this mail.
>
>      I initialy wrote it to stress the mode change mechanics, but then I
>      noticed the massive difference when I ran it on upstream:
>
> 		8 pools / 8 threads	32 pools / 32 threads
>
>      v6.17	  23666 thr/sec	       16161 thr/sec
>      +rseq/perf	  23656 thr/sec	 0%    16196 thr/sec	 0%	
>      +cid rework  32025 thr/sec	 +35%  21004 thr/sec	+30%
>
>      Both v6.17 and v6.17 + rseq/perf show this in perf top:
>
>       14.62%  [kernel]     [k] update_sd_lb_stats.constprop.0
>       13.08%  [kernel]     [k] native_queued_spin_lock_slowpath
>        4.66%  [kernel]     [k] osq_lock
>        3.06%  [kernel]     [k] _find_next_and_bit
>        2.21%  [kernel]     [k] __schedule
>        2.16%  [kernel]     [k] sched_balance_rq
>
>     with the CID rewrite this becomes:
>
>      13.48%  [kernel]      [k] native_queued_spin_lock_slowpath
>       8.98%  [kernel]      [k] update_sd_lb_stats.constprop.0
>       5.16%  [kernel]      [k] osq_lock
>       2.28%  [kernel]      [k] _find_next_and_bit
>       2.11%  [kernel]      [k] __schedule
>       1.75%  [kernel]      [k] psi_group_change
>       ...
>       1.32%  [kernel]      [k] sched_balance_rq
>
>    I haven't been able to understand that massive difference yet.

Looked deeper into it and it turns out that the problem is caused by the
upstream MM_CID implmementation. The extra work in the task migration
code increases rq lock hold time enough to cause that.

When I make CONFIG_SCHED_MM_CID a real knob and disable it on top of
rseq/perf then it becomes on par with the rewritten CID code. Toggling
it on top of the CID rewrite series does not really make a difference.

Thanks,

        tglx