Re: [PATCH v3 17/20] sched/core: Introduce default arch handling code for inc/dec preferred CPUs

[Shrikanth Hegde]

On 6/8/26 9:52 PM, Ilya Leoshkevich wrote:
> > +#ifndef arch_dec_preferred_cpus
> > +void arch_dec_preferred_cpus(struct steal_monitor_t *sm, u64 
> > steal_ratio)
> > +{
> > +    int last_cpu, tmp_cpu;
> > +    int this_cpu = raw_smp_processor_id();
> > +
> > +    cpumask_and(sm->tmp_mask, cpu_online_mask, cpu_preferred_mask);
> > +    last_cpu = cpumask_last(sm->tmp_mask);
> > +
> > +    /*
> > +     * If the core belongs to the housekeeping CPUs, no action is
> > +     * taken. This leaves at least one core preferred always.
> > +     * This ensures at least some CPUs are available to run
> > +     */
> > +    if (cpumask_equal(cpu_smt_mask(last_cpu), cpu_smt_mask(this_cpu)))
> > +        return;
> > +
> > +    for_each_cpu_and(tmp_cpu, cpu_smt_mask(last_cpu), cpu_online_mask) {
> > +        set_cpu_preferred(tmp_cpu, false);
> > +        if (tick_nohz_full_cpu(tmp_cpu))
> > +            tick_nohz_dep_set_cpu(tmp_cpu, TICK_DEP_BIT_SCHED);
>
> Should the opposite be done in arch_inc_preferred_cpus()?

No. This is done so that tick gets enabled on nohz_full CPU and
push depends on the tick being enabled for fast action.

When it is enabled, there is no dependency on tick to spread the task out.
It happens via wake-up or load balance.
Load balance seems to be quick enough when spreading the task out.

> If not, it would be good to write a comment explaining why; this
> asymmetry catches the eye.

Ack.

> > +    }
> > +}
> > +#endif
> > +