On 03/02/2021 14:12, Vincent Guittot wrote: > On Wed, 3 Feb 2021 at 12:54, Dietmar Eggemann <dietmar.eggem...@arm.com> > wrote: >> >> On 29/01/2021 18:27, Vincent Guittot wrote: >>> Le vendredi 29 janv. 2021 � 11:33:00 (+0100), Vincent Guittot a �crit : >>>> On Thu, 28 Jan 2021 at 16:09, Joel Fernandes <j...@joelfernandes.org> >>>> wrote: >>>>> >>>>> Hi Vincent, >>>>> >>>>> On Thu, Jan 28, 2021 at 8:57 AM Vincent Guittot >>>>> <vincent.guit...@linaro.org> wrote: >>>>>>> On Mon, Jan 25, 2021 at 03:42:41PM +0100, Vincent Guittot wrote: >>>>>>>> On Fri, 22 Jan 2021 at 20:10, Joel Fernandes <j...@joelfernandes.org> >>>>>>>> wrote: >>>>>>>>> On Fri, Jan 22, 2021 at 05:56:22PM +0100, Vincent Guittot wrote: >>>>>>>>>> On Fri, 22 Jan 2021 at 16:46, Joel Fernandes (Google) >>>>>>>>>> <j...@joelfernandes.org> wrote: >> >> [...] >> >>>> The only point that I agree with, is that running >>>> update_blocked_averages with preempt and irq off is not a good thing >>>> because we don't manage the number of csf_rq to update and I'm going >>>> to provide a patchset for this >>> >>> The patch below moves the update of the blocked load of CPUs outside >>> newidle_balance(). >>> >>> Instead, the update is done with the usual idle load balance update. I'm >>> working on an >>> additonnal patch that will select this cpu that is about to become idle, >>> instead of a >>> random idle cpu but this 1st step fixe the problem of lot of update in >>> newly idle. >> >> I'm trying to understand the need for this extra patch. >> >> The patch below moves away from doing update_blocked_averages() (1) for >> all CPUs in sched groups of the sched domain: >> >> newidle_balance()->load_balance()-> >> find_busiest_group()->update_sd_lb_stats()->update_sg_lb_stats() >> >> to: >> >> calling (1) for CPUs in nohz.idle_cpus_mask in _nohz_idle_balance() via >> update_nohz_stats() and for the ilb CPU. >> >> newidle_balance() calls (1) for newidle CPU already. >> >> What would be the benefit to choose newidle CPU as ilb CPU? > > To prevent waking up another idle cpu to run the update whereas > newidle cpu is already woken up and about to be idle so the best > candidate. > All the aim of the removed code was to prevent waking up an idle cpu > for doing something that could be done by the newidle cpu before it > enters idle state
Ah OK, makes sense. So the only diff would be that newidle CPU will call (1) on nohz.idle_cpus_mask rather on on sd->span. [...]
