Re: [RFC PATCHC 0/3] sched/idle : find the idlest cpu with cpuidle info

[Nicolas Pitre <nicolas.pitre@linaro.org>]

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