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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
