linux-kernel - Re: [RFC PATCH v3 03/10] sched: Static key to check paravirt cpu push

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: <aMLq6ht48Mej_4zW@yury>
Date: Thu, 11 Sep 2025 11:29:46 -0400
From: Yury Norov <yury.norov@...il.com>
To: Shrikanth Hegde <sshegde@...ux.ibm.com>
Cc: mingo@...hat.com, peterz@...radead.org, juri.lelli@...hat.com,
	vincent.guittot@...aro.org, tglx@...utronix.de, maddy@...ux.ibm.com,
	linux-kernel@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org,
	gregkh@...uxfoundation.org, vschneid@...hat.com, iii@...ux.ibm.com,
	huschle@...ux.ibm.com, rostedt@...dmis.org,
	dietmar.eggemann@....com, vineeth@...byteword.org, jgross@...e.com,
	pbonzini@...hat.com, seanjc@...gle.com
Subject: Re: [RFC PATCH v3 03/10] sched: Static key to check paravirt cpu push

On Thu, Sep 11, 2025 at 08:07:46PM +0530, Shrikanth Hegde wrote:
> 
> 
> On 9/11/25 7:23 AM, Yury Norov wrote:
> > On Wed, Sep 10, 2025 at 11:12:03PM +0530, Shrikanth Hegde wrote:
> > > CPUs are marked paravirt when there is contention for underlying
> > > physical CPU.
> > > 
> > > The push mechanism and check for paravirt CPUs are in sched tick
> > > and wakeup. It should be close to no-op when there is no need for it.
> > > Achieve that using static key.
> > > 
> > > Architecture needs to enable this key when it decides there are
> > > paravirt CPUs. Disable it when there are no paravirt CPUs.
> > 
> 
> Hi Yury, Thanks for looking into this series.
> 
> > Testing a bit is quite close to a no-op, isn't it? Have you measured
> > the performance impact that would advocate the static key? Please
> > share some numbers then. I believe I asked you about it on the previous
> > round.
> 
> The reasons I thought to keep are:
> 
> 1. In load balance there is cpumask_and which does a loop.
> Might be better to avoid it when it is not necessary.
> 
> 2. Since __cpu_paravirt_mask is going to in one of the memory node in large NUMA systems
> (likely on boot cpu node), access to it from other nodes might take time and costly when
> it is not in cache. one could say same for static key too. but cpumask can be large when
> NR_CPUS=8192 or so.
>
> 
> In most of the cases hackbench,schbench didn't show much difference.
 
So, you're adding a complication for no clear benefit. Just drop it.