Re: [PATCH 1/2] sched/fair: consider hk_mask early in triggering ilb

[Peter Zijlstra <peterz@infradead.org>]

On Fri, Mar 20, 2026 at 02:49:30PM +0530, Shrikanth Hegde wrote:
> 
> 
> On 3/20/26 9:07 AM, K Prateek Nayak wrote:
> > Hello Shrikanth,
> > 
> > On 3/19/2026 12:23 PM, Shrikanth Hegde wrote:
> > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > > index b19aeaa51ebc..02cca2c7a98d 100644
> > > --- a/kernel/sched/fair.c
> > > +++ b/kernel/sched/fair.c
> > > @@ -7392,6 +7392,7 @@ static inline unsigned int cfs_h_nr_delayed(struct rq *rq)
> > >   static DEFINE_PER_CPU(cpumask_var_t, load_balance_mask);
> > >   static DEFINE_PER_CPU(cpumask_var_t, select_rq_mask);
> > >   static DEFINE_PER_CPU(cpumask_var_t, should_we_balance_tmpmask);
> > > +static DEFINE_PER_CPU(cpumask_var_t, kick_ilb_tmpmask);
> > 
> > nit. We can rename and reuse select_rq_mask. Wakeups happen with IRQs
> > disabled and kick happens from the hrtimer handler so it should be safe
> > to reuse that and save some space.
> > 
> > Thoughts?
> 
> May be. but it could be a confusing name. sched_tmpmask?
> 
> We could similar stuff already to load_balance_mask, select_rq_mask.
> So, i would prefer to keep it separate.

But then we keep growing this ad infinitum.

The more sensible option is to name them after the context and have
get/put accessors that (for PROVE_LOCKING builds or so) verify the
context and maybe even 'lock' them to make sure nobody is trying to use
one for two things at the same time.

That should make it clearer whats what and improve reuse, no?