Re: [PATCH V3 2/2] sched/fair: Fallback to sched-idle CPU if idle CPU isn't found

From: Subhra Mazumdar
Date: Mon Jul 01 2019 - 18:14:49 EST



On 7/1/19 1:03 AM, Viresh Kumar wrote:
On 28-06-19, 18:16, Subhra Mazumdar wrote:
On 6/25/19 10:06 PM, Viresh Kumar wrote:
We try to find an idle CPU to run the next task, but in case we don't
find an idle CPU it is better to pick a CPU which will run the task the
soonest, for performance reason.

A CPU which isn't idle but has only SCHED_IDLE activity queued on it
should be a good target based on this criteria as any normal fair task
will most likely preempt the currently running SCHED_IDLE task
immediately. In fact, choosing a SCHED_IDLE CPU over a fully idle one
shall give better results as it should be able to run the task sooner
than an idle CPU (which requires to be woken up from an idle state).

This patch updates both fast and slow paths with this optimization.

Signed-off-by: Viresh Kumar <viresh.kumar@xxxxxxxxxx>
---
kernel/sched/fair.c | 43 +++++++++++++++++++++++++++++++++----------
1 file changed, 33 insertions(+), 10 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 1277adc3e7ed..2e0527fd468c 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -5376,6 +5376,15 @@ static struct {
#endif /* CONFIG_NO_HZ_COMMON */
+/* CPU only has SCHED_IDLE tasks enqueued */
+static int sched_idle_cpu(int cpu)
+{
+ struct rq *rq = cpu_rq(cpu);
+
+ return unlikely(rq->nr_running == rq->cfs.idle_h_nr_running &&
+ rq->nr_running);
+}
+
Shouldn't this check if rq->curr is also sched idle?
Why wouldn't the current set of checks be enough to guarantee that ?
I thought nr_running does not include the on-cpu thread.

And why not drop the rq->nr_running non zero check?
Because CPU isn't sched-idle if nr_running and idle_h_nr_running are both 0,
i.e. it is an IDLE cpu in that case. And so I thought it is important to have
this check as well.

idle_cpu() not only checks nr_running is 0 but also rq->curr == rq->idle