[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160511070029.GE3193@twins.programming.kicks-ass.net>
Date: Wed, 11 May 2016 09:00:29 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Yuyang Du <yuyang.du@...el.com>
Cc: mingo@...nel.org, linux-kernel@...r.kernel.org, clm@...com,
matt@...eblueprint.co.uk, mgalbraith@...e.de, tglx@...utronix.de,
fweisbec@...il.com
Subject: Re: [RFC][PATCH 5/7] sched: Rewrite select_idle_siblings()
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.
> Then, I am still considering combining them a bit, like the following patch.
> And if you want, more might be combined.
I tried that (and you really want the last idle it finds, to minimize
the time between testing for idle and returning it), but it didn't
matter for anything I could find.
Powered by blists - more mailing lists