linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Yuyang Du <yuyang.du@intel.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: mingo@kernel.org, linux-kernel@vger.kernel.org, clm@fb.com,
	matt@codeblueprint.co.uk, mgalbraith@suse.de, tglx@linutronix.de,
	fweisbec@gmail.com
Subject: Re: [RFC][PATCH 5/7] sched: Rewrite select_idle_siblings()
Date: Wed, 11 May 2016 07:42:30 +0800	[thread overview]
Message-ID: <20160510234230.GC4870@intel.com> (raw)
In-Reply-To: <20160511070029.GE3193@twins.programming.kicks-ass.net>

On Wed, May 11, 2016 at 09:00:29AM +0200, Peter Zijlstra wrote:
> On Wed, May 11, 2016 at 05:05:50AM +0800, Yuyang Du wrote:
> > On Mon, May 09, 2016 at 12:48:12PM +0200, Peter Zijlstra wrote:
> > > +	i = select_idle_core(p, sd, target);
> > > +	if ((unsigned)i < nr_cpumask_bits)
> > > +		return i;
> > > +
> > > +	i = select_idle_cpu(p, sd, target);
> > > +	if ((unsigned)i < nr_cpumask_bits)
> > > +		return i;
> > > +
> > > +	i = select_idle_smt(p, sd, target);
> > > +	if ((unsigned)i < nr_cpumask_bits)
> > > +		return i;
> > 
> > First, on smt, these three scans have a lot of overlap,
> 
> Limited, we stop doing the idle_core scan the moment we fail to find
> one. And on a busy system it is unlikely to come back.
> 
> Which leaves us with the straight idle_cpu scan. Sure, the one time we
> fail to find an idle core and fall through we'll scan double, but that
> should be rare.

Yes, I was sorta well educated about how important finding an idle is ("one
stack, game over"), which therefore is sure worth the effort.

Looks to me, it is just about how much opportunisic-spinning should be applied
here. Great.

Do you have any suggestion about doing other part of select_task_rq_fair?

  reply	other threads:[~2016-05-11  7:24 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-09 10:48 [RFC][PATCH 0/7] sched: select_idle_siblings rewrite Peter Zijlstra
2016-05-09 10:48 ` [RFC][PATCH 1/7] sched: Remove unused @cpu argument from destroy_sched_domain*() Peter Zijlstra
2016-05-09 10:48 ` [RFC][PATCH 2/7] sched: Restructure destroy_sched_domain() Peter Zijlstra
2016-05-09 14:46   ` Peter Zijlstra
2016-05-09 10:48 ` [RFC][PATCH 3/7] sched: Introduce struct sched_domain_shared Peter Zijlstra
2016-05-09 10:48 ` [RFC][PATCH 4/7] sched: Replace sd_busy/nr_busy_cpus with sched_domain_shared Peter Zijlstra
2016-05-11 11:55   ` Matt Fleming
2016-05-11 12:33     ` Peter Zijlstra
2016-05-11 18:11       ` Peter Zijlstra
2016-05-11 18:24       ` Peter Zijlstra
2016-05-12  2:05         ` Michael Neuling
2016-05-12  5:07           ` Peter Zijlstra
2016-05-12 11:07             ` Michael Neuling
2016-05-12 11:33               ` Peter Zijlstra
2016-05-13  0:12                 ` Michael Neuling
2016-05-16 14:00                   ` Peter Zijlstra
2016-05-17 10:20                     ` Peter Zijlstra
2016-05-17 10:52                       ` Srikar Dronamraju
2016-05-17 11:15                         ` Peter Zijlstra
2016-05-11 17:37     ` Peter Zijlstra
2016-05-11 18:04       ` Matt Fleming
2016-05-16 15:31   ` Dietmar Eggemann
2016-05-16 17:02     ` Peter Zijlstra
2016-05-16 17:26       ` Dietmar Eggemann
2016-05-09 10:48 ` [RFC][PATCH 5/7] sched: Rewrite select_idle_siblings() Peter Zijlstra
2016-05-10 21:05   ` Yuyang Du
2016-05-11  7:00     ` Peter Zijlstra
2016-05-10 23:42       ` Yuyang Du [this message]
2016-05-11  7:43         ` Mike Galbraith
2016-05-09 10:48 ` [RFC][PATCH 6/7] sched: Optimize SCHED_SMT Peter Zijlstra
2016-05-09 10:48 ` [RFC][PATCH 7/7] sched: debug muck -- not for merging Peter Zijlstra
2016-05-10  0:50 ` [RFC][PATCH 0/7] sched: select_idle_siblings rewrite Chris Mason
2016-05-11 14:19 ` Chris Mason
2016-05-18  5:51 ` [RFC][PATCH 8/7] sched/fair: Use utilization distance to filter affine sync wakeups Mike Galbraith
2016-05-19 21:43   ` Rik van Riel
2016-05-20  2:52     ` Mike Galbraith
2016-05-25 14:51 ` [RFC][PATCH 0/7] sched: select_idle_siblings rewrite Chris Mason
2016-05-25 16:24   ` Peter Zijlstra
2016-05-25 17:11     ` Chris Mason

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=20160510234230.GC4870@intel.com \
    --to=yuyang.du@intel.com \
    --cc=clm@fb.com \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matt@codeblueprint.co.uk \
    --cc=mgalbraith@suse.de \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    /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;
as well as URLs for NNTP newsgroup(s).