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 <[email protected]> > > --- > > 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 ? > 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. -- viresh
