public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mel Gorman <mgorman@techsingularity.net>
To: "Li, Aubrey" <aubrey.li@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Qais Yousef <qais.yousef@arm.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 5/5] sched/fair: Merge select_idle_core/cpu()
Date: Mon, 18 Jan 2021 14:41:19 +0000	[thread overview]
Message-ID: <20210118144119.GR3592@techsingularity.net> (raw)
In-Reply-To: <05522d03-e86d-420e-4e88-f098d9a22908@linux.intel.com>

On Mon, Jan 18, 2021 at 08:55:03PM +0800, Li, Aubrey wrote:
> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > index 12e08da90024..6c0f841e9e75 100644
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> > @@ -6006,6 +6006,14 @@ static inline int find_idlest_cpu(struct sched_domain *sd, struct task_struct *p
> >  	return new_cpu;
> >  }
> >  
> > +static inline int __select_idle_cpu(struct task_struct *p, int core, struct cpumask *cpus)
> 
> Sorry if I missed anything, why p and cpus are needed here?
> 

They are not needed. The original code was matching the calling pattern
for select_idle_core() which needs p and cpus to check if sibling CPUs
are allowed.

> > @@ -6135,7 +6147,7 @@ static int select_idle_cpu(struct task_struct *p, struct sched_domain *sd, int t
> >  
> >  	cpumask_and(cpus, sched_domain_span(sd), p->cpus_ptr);
> >  
> > -	if (sched_feat(SIS_PROP)) {
> > +	if (sched_feat(SIS_PROP) && !smt) {
>
> Is it possible the system does have a idle core, but I still don't want to scan the entire llc domain?
> 

This version is matching historical behaviour. To limit the scan for cores,
select_idle_core() would need to obey SIS_PROP and that patch was dropped
as it introduced regressions. It would only be considered once SIS_PROP
had better metrics for limiting the depth of the search.

> >  		u64 avg_cost, avg_idle, span_avg;
> >  
> >  		/*
> > @@ -6159,16 +6171,29 @@ static int select_idle_cpu(struct task_struct *p, struct sched_domain *sd, int t
> >  	for_each_cpu_wrap(cpu, cpus, target) {
> >  		if (!--nr)
> >  			return -1;
> 
> It looks like nr only makes sense when smt = false now, can it be moved into else branch below?
> 

It can. I expect the saving to be marginal and it will need to move back
when/if select_idle_core() obeys SIS_PROP.

> > -		if (available_idle_cpu(cpu) || sched_idle_cpu(cpu))
> > -			break;
> > +		if (smt) {
> > +			i = select_idle_core(p, cpu, cpus, &idle_cpu);
> > +			if ((unsigned int)i < nr_cpumask_bits)
> > +				return i;
> 
> What if the last idle core is selected here, should we set_idle_cores false before return?
> 

We'd have to check what bits were still set in the cpus mask and
determine if they represent an idle core. I severely doubt it would be
worth the cost given that the availability of idle cores can change at
any instant.

-- 
Mel Gorman
SUSE Labs

  reply	other threads:[~2021-01-18 14:43 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-15 10:08 [PATCH v2 0/5] Scan for an idle sibling in a single pass Mel Gorman
2021-01-15 10:08 ` [PATCH 1/5] sched/fair: Remove SIS_AVG_CPU Mel Gorman
2021-01-15 10:08 ` [PATCH 2/5] sched/fair: Move avg_scan_cost calculations under SIS_PROP Mel Gorman
2021-01-15 10:08 ` [PATCH 3/5] sched/fair: Make select_idle_cpu() proportional to cores Mel Gorman
2021-01-18  8:14   ` Li, Aubrey
2021-01-18  9:27     ` Mel Gorman
2021-01-15 10:08 ` [PATCH 4/5] sched/fair: Remove select_idle_smt() Mel Gorman
2021-01-15 10:08 ` [PATCH 5/5] sched/fair: Merge select_idle_core/cpu() Mel Gorman
2021-01-18 12:55   ` Li, Aubrey
2021-01-18 14:41     ` Mel Gorman [this message]
  -- strict thread matches above, loose matches on Subject: below --
2021-01-19 11:22 [PATCH v3 0/5] Scan for an idle sibling in a single pass Mel Gorman
2021-01-19 11:22 ` [PATCH 5/5] sched/fair: Merge select_idle_core/cpu() Mel Gorman
2021-01-20  8:30   ` Gautham R Shenoy
2021-01-20  9:12     ` Mel Gorman
2021-01-20  9:21       ` Vincent Guittot
2021-01-20  9:54         ` Mel Gorman
2021-01-20  9:58           ` Vincent Guittot
2021-01-20 13:55           ` Gautham R Shenoy
2021-01-11 15:50 [PATCH 0/5] Scan for an idle sibling in a single pass Mel Gorman
2021-01-11 15:50 ` [PATCH 5/5] sched/fair: Merge select_idle_core/cpu() Mel Gorman
2021-01-13 17:03   ` Vincent Guittot
2021-01-14  9:35     ` Mel Gorman
2021-01-14 13:25       ` Vincent Guittot
2021-01-14 13:53         ` Mel Gorman
2021-01-14 15:44           ` Vincent Guittot
2021-01-14 17:18             ` Mel Gorman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210118144119.GR3592@techsingularity.net \
    --to=mgorman@techsingularity.net \
    --cc=aubrey.li@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=qais.yousef@arm.com \
    --cc=vincent.guittot@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox