Re: [PATCH] sched/fair: Distribute burst-woken tasks when rq depth reaches 3x average

[Li kunyu <likunyu@open-hieco.net>]

On 2026/11/6 0:46, Kayra Cizmeci wrote:
>> Here, the existing logic is reused, with new_cpu used as the final return value.
> It's not used as the final return value. We return dist_cpu not new_cpu.
> Look below :-).

The latest code now calls reset_periodic_lb_interval(dist_cpu);. Yesterday's
testing indicated that this change could be further optimized and did not have a
significant impact. The implementation of reset_periodic_lb_interval() has now
been modified as follows:

+static inline void reset_periodic_lb_interval(struct rq *rq)
+{
+       unsigned long now = jiffies;
+
+       if (time_after(READ_ONCE(rq->next_balance), now))
+               WRITE_ONCE(rq->next_balance, now);
+}


>> It remains unclear whether this approach is appropriate. If it causes no
>> practical impact, it seems reasonable to keep it unchanged.
>>
>>>> +			return dist_cpu;
>>>> +		}
>>>> +	}
>>>>  
> 
> Well, if we chose dist_cpu instead of new_cpu why we are calling
> reset_periodic_lb_interval() thingie for new_cpu?
> 
> Even calling it for dist_cpu is questionable.
> 
> 
> Because:
> 
> sched_balance_domains() gets the interval value from
> get_sd_balance_interval(). get_sd_balance_interval() reads the value
> from sd->balance_interval (The value we are resetting) and multiplies it
> by busy_factor if the cpu_busy bool parameter is true.
> 
> sched_balance_domains() calls sched_balance_rq() if jiffies is bigger or equal to
> last_balance + interval.
> 
> Now as you can see, we make the interval value bigger when the CPU is
> busy. In your path, if the new_cpu is not the picked CPU calling this
> makes no sense. Because if we didn't picked it, it already means that
> it's busy or atleast worse than the other options.
> 
> sched_balance_rq() already tries to pull the tasks to the given CPU at
> first place.
> 
> 
> If we really wanna do that, atleast call it for dist_cpu (the returned CPU) not
> for the CPU that lost.
> 
> Or am I getting something wrong?


Should the assignment to sd->balance_interval from the previous version still be
kept? It has been removed in the current test version.

-- 
thanks,
kunyu