Messages in this thread | | | From | Vincent Guittot <> | Date | Fri, 4 Dec 2020 14:13:08 +0100 | Subject | Re: [PATCH 06/10] sched/fair: Clear the target CPU from the cpumask of CPUs searched |
| |
On Fri, 4 Dec 2020 at 12:30, Mel Gorman <mgorman@techsingularity.net> wrote: > > On Fri, Dec 04, 2020 at 11:56:36AM +0100, Vincent Guittot wrote: > > > The intent was that the sibling might still be an idle candidate. In > > > the current draft of the series, I do not even clear this so that the > > > SMT sibling is considered as an idle candidate. The reasoning is that if > > > there are no idle cores then an SMT sibling of the target is as good an > > > idle CPU to select as any. > > > > Isn't the purpose of select_idle_smt ? > > > > Only in part. > > > select_idle_core() looks for an idle core and opportunistically saves > > an idle CPU candidate to skip select_idle_cpu. In this case this is > > useless loops for select_idle_core() because we are sure that the core > > is not idle > > > > If select_idle_core() finds an idle candidate other than the sibling, > it'll use it if there is no idle core -- it picks a busy sibling based > on a linear walk of the cpumask. Similarly, select_idle_cpu() is not
My point is that it's a waste of time to loop the sibling cpus of target in select_idle_core because it will not help to find an idle core. The sibling cpus will then be check either by select_idle_cpu of select_idle_smt
> guaranteed to scan the sibling first (ordering) or even reach the sibling > (throttling). select_idle_smt() is a last-ditch effort. > > -- > Mel Gorman > SUSE Labs
| |