[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.11.1404151111470.980@knanqh.ubzr>
Date: Tue, 15 Apr 2014 11:27:28 -0400 (EDT)
From: Nicolas Pitre <nicolas.pitre@...aro.org>
To: Peter Zijlstra <peterz@...radead.org>
cc: "Rafael J. Wysocki" <rjw@...ysocki.net>,
Daniel Lezcano <daniel.lezcano@...aro.org>,
linux-kernel@...r.kernel.org, mingo@...e.hu,
linux-pm@...r.kernel.org, alex.shi@...aro.org,
vincent.guittot@...aro.org, morten.rasmussen@....com
Subject: Re: [RFC PATCHC 0/3] sched/idle : find the idlest cpu with cpuidle
info
On Tue, 15 Apr 2014, Peter Zijlstra wrote:
> On Fri, Apr 04, 2014 at 01:43:00PM +0200, Rafael J. Wysocki wrote:
> > > That's what this patch series is about. The find_idlest_cpu code should
> > > look for the idle CPU with the shallowest idle state, or the one with
> > > the smallest load. In this context "find_idlest_cpu" might become a
> > > misnomer.
> >
> > Yes, clearly. It should be called find_best_cpu or something like that.
>
> Ha!, but for what purpose? We already have find_busiest_cpu() to find
> the CPU to steal work from. The converse action, currently called
> find_idlest_cpu() is finding the CPU where to put work.
>
> 'Best' is ambiguous in all regards, it doesn't convey the direction nor
> the quality sorted on.
>
> So while idlest might be somewhat of a misnomer, it at least conveys the
> directional thing fairly well. Also we are still searching the least
> busy, and preferable an idle, cpu. 'Idlest' being a superlative also
> conveys the meaning of order.
I agree that anything which is called "best" is ambigous. Best for
what? That isn't self explanatory.
However "idlest" is no longer the wanted attribute here. "Least busy"
is right. But not necessarily the "idlest". The "best" CPU here is
somewhat in the middle between busiest and idlest i.e. preferably idle,
but not the "idlest" in the cpuidle sense.
Maybe we could use your definition to simply call it
find_cpu_to_put_work() or the like. Today this is based on the idleness
of CPUs, but eventually we'll want to pack tasks on already loaded CPUs
(without oversubscribing them) in order to keep as many CPUs idle as
possible when that makes sense, which would alter the selection
somewhat.
Nicolas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists