Re: [PATCH 2/3] sched/fair: Introduce scaled capacity awareness in select_idle_sibling code path

[Rohit Jain]

Hi Atish,

Thanks for the comments

On 10/10/2017 08:54 AM, Atish Patra wrote:
> <snip>
> > Signed-off-by: Rohit Jain <rohit.k.jain@xxxxxxxxxx>
> > ---
> > Â kernel/sched/fair.c | 37 ++++++++++++++++++++++++++++---------
> > Â 1 file changed, 28 insertions(+), 9 deletions(-)
> >
> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > index eaede50..5b1f7b9 100644
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> > @@ -6004,7 +6004,7 @@ static int select_idle_core(struct task_struct 
> > *p, struct sched_domain *sd, int
> > Â ÂÂÂÂÂÂÂÂÂ for_each_cpu(cpu, cpu_smt_mask(core)) {
> > ÂÂÂÂÂÂÂÂÂÂÂÂÂ cpumask_clear_cpu(cpu, cpus);
> > -ÂÂÂÂÂÂÂÂÂÂÂ if (!idle_cpu(cpu))
> > +ÂÂÂÂÂÂÂÂÂÂÂ if (!idle_cpu(cpu) || !full_capacity(cpu))
> Do we need to skip the entire core just because 1st cpu in the core 
> doesn't have full capacity ?
> Let's say that is the only idle core available. It will go and try to 
> select_idle_cpu() to find the idlest cpu.
> Is it worth spending extra time to search an idle cpu with full 
> capacity when there are idle cores available ?

This has been previously discussed:
https://lkml.org/lkml/2017/10/3/1001

Returning the best CPU within the idle core did not result in a
statistically significant performance benefit, hence I went with Joel's
suggestion to keep the code simple.

Thanks,
Rohit

<snip>