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

[Yury Norov <yury.norov@gmail.com>]

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.