lkml.org 
[lkml]   [2014]   [Apr]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCHC 3/3] sched/fair: use the idle state info to choose the idlest cpu
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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2014-04-18 14:41    [W:0.092 / U:0.608 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site