Re: [PATCH v4 7/7] sched/fair: de-entropy for SIS filter

[Abel Wu]

On 6/22/22 2:23 AM, Chen Yu Wrote:
> On Sun, Jun 19, 2022 at 08:04:51PM +0800, Abel Wu wrote:
> > ...
> > @@ -8777,7 +8778,11 @@ static inline void update_sg_lb_stats(struct lb_env *env,
> >   		nr_running = rq->nr_running;
> >   		sgs->sum_nr_running += nr_running;
> >   
> > -		if (update_core)
> > +		/*
> > +		 * The dst_cpu is not preferred since it might
> > +		 * be fed with tasks soon.
> > +		 */
> > +		if (update)
> maybe if (update_core && (env->dst_cpu != i)) so that the comment would
> be near the code logic and meanwhile without introducing a update variable?

Makes sense.

> > ...
> > @@ -9331,6 +9337,22 @@ static void sd_update_state(struct lb_env *env, struct sd_lb_stats *sds)
> >   	if (cmpxchg(&sd_smt_shared->updating, 0, 1))
> >   		return;
> >   
> > +	/*
> > +	 * The dst_cpu is likely to be fed with tasks soon.
> > +	 * If it is the only unoccupied cpu in this domain,
> > +	 * we still handle it the same way as as_has_icpus
> > +	 * but turn the SMT into the unstable state, rather
> > +	 * than waiting to the end of load balancing since
> > +	 * it's also important that update the filter as
> > +	 * early as possible to keep it fresh.
> > +	 */
> > +	if (new == sd_is_busy) {
> > +		if (idle_cpu(this) || sched_idle_cpu(this)) {
> available_idle_cpu()?

It is used for choosing an idle cpu that will be immediately used,
so generally inside the wakeup path. But here we just want to know
the idle state of the cpus (and later inside wakeup path these cpus
will still be re-checked to see if they are preempted).

Thanks & BR,
Abel