On Tue, Jan 23, 2024 at 10:28:31AM +0530, K Prateek Nayak wrote:
> Hello Tim,
> 
> On 1/23/2024 3:29 AM, Tim Chen wrote:
> > On Fri, 2024-01-19 at 14:15 +0530, K Prateek Nayak wrote:
> >>
> >> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> >> index b803030c3a03..1fedc7e29c98 100644
> >> --- a/kernel/sched/fair.c
> >> +++ b/kernel/sched/fair.c
> >> @@ -8499,6 +8499,16 @@ done: __maybe_unused;
> >>  	if (!rf)
> >>  		return NULL;
> >>  
> >> +	/*
> >> +	 * An idle CPU in TIF_POLLING mode might end up here after processing
> >> +	 * an IPI when the sender sets the TIF_NEED_RESCHED bit and avoids
> >> +	 * sending an actual IPI. In such cases, where an idle CPU was woken
> >> +	 * up only to process an interrupt, without necessarily queuing a task
> >> +	 * on it, skip newidle_balance() to facilitate faster idle re-entry.
> >> +	 */
> >> +	if (prev == rq->idle)
> >> +		return NULL;
> >> +
> > 
> > Should we check the call function queue directly to detect that there is
> > an IPI waiting to be processed? something like
> > 
> > 	if (!llist_empty(&per_cpu(call_single_queue, rq->cpu)))
> > 		return NULL;
> 
> That could be a valid check too. However, if an IPI is queued right
> after this check, the processing is still delayed since
> newidle_balance() only bails out for scenarios when a wakeup is trying
> to queue a new task on the CPU running the newidle_balance().
> 
> > 
> > Could there be cases where we want to do idle balance in this code path?
> > Say a cpu is idle and a scheduling tick came in, we may try
> > to look for something to run on the idle cpu.  Seems like after
> > your change above, that would be skipped.
> 
> Wouldn't scheduler_tick() do load balancing when the time comes? In my
> testing, I did not see a case where the workloads I tested were
> sensitive to the aspect of newidle_balance() being invoked at scheduler
> tick. Have you come across a workload which might be sensitive to this
> aspect that I can quickly test and verify? Meanwhile, I'll run the
> workloads mentioned in the commit log on an Intel system to see if I
> can spot any sensitivity to this change.
> 
> Adding David to the thread too since HHVM seems to be one of those
> workloads that is very sensitive to a successful newidle_balance().

Thanks for the cc. FWIW, I think a lot of things are very sensitive to
timing in newidle_balance(), but it goes both ways. For example, we had
to revert commit e60b56e46b38 ("sched/fair: Wait before decaying
max_newidle_lb_cost") [0] on our internal kernel because it regressed
some workloads by causing us to load_balance() too frequently. I think
the fix is correct in that there's no reason we shouldn't apply the ~1%
decay / second to newidle lb cost in newidle_balance(), but by causing
us to (correctly) decay newidle lb cost in newidle_balance(), it also
increased CPU util rather significantly and had us spending too much
time in load_balance().

[0]: https://lore.kernel.org/all/20211019123537.17146-4-vincent.guittot@linaro.org/

On the other hand, on other hosts, we use SHARED_RUNQ to load balance as
aggressively as possible, and those hosts would have benefited from that
change if SHARED_RUNQ wasn't an option.

My 2 cents is that I think it's impossible to make everyone happy, and I
think the change here makes sense. If there's imbalance, it's something
we would uncover when load_balance() is kicked off on the tick path
anyways. I also agree with Vincent [1] that your idea / prototype of
adding a TIF_NEED_IPI flag is an overall better solution, but this does
seem fine to me as well in the interim.

[1]: https://lore.kernel.org/all/CAKfTPtC446Lo9CATPp7PExdkLhHQFoBuY-JMGC7agOHY4hs-Pw@mail.gmail.com/

Thanks,
David