Re: [RFC PATCHC 3/3] sched/fair: use the idle state info to choose the idlest cpu

[Daniel Lezcano <daniel.lezcano@linaro.org>]

On 04/18/2014 11:38 AM, Peter Zijlstra wrote:
> On Thu, Apr 17, 2014 at 12:21:28PM -0400, Nicolas Pitre wrote:
>> CPU topology is needed to properly describe scheduling domains.  Whether
>> we balance across domains or pack using as few domains as possible is a
>> separate issue.  In other words, you shouldn't have to care in this
>> patch series.
>>
>> And IMHO coupled C-state is a low-level mechanism that should remain
>> private to cpuidle which the scheduler shouldn't be aware of.
>
> I'm confused.. why wouldn't you want to expose these?

The couple C-state is used as a mechanism for cpuidle to sync the cpus 
when entering a specific c-state. This mechanism is usually used to 
handle the cluster power down. It is only used for a two drivers (soon 
three) but it is not the only mechanism used for syncing the cpus. There 
are also the MCPM (tc2), the hand made sync when the hardware allows it 
(ux500), and an abstraction from the firmware (mwait), transparent to 
the kernel.

Taking into account the couple c-state only does not make sense because 
of the other mechanisms above. This is why it should stay inside the 
cpuidle framework.

The extension of the cpu topology will provide a generic way to describe 
and abstracting such dependencies.

Does it answer your question ?

   -- Daniel

-- 
  <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog