Re: [RFC PATCH 3/3] idle: store the idle state index in the structrq
From: Daniel Lezcano
Date: Fri Jan 31 2014 - 10:37:42 EST
On 01/31/2014 04:07 PM, Arjan van de Ven wrote:
Hence I think this patch would make sense only with additional
information
like exit_latency or target_residency is present for the scheduler.
The idle
state index alone will not be sufficient.
Alternatively, can we enforce sanity on the cpuidle infrastructure to
make the index naturally ordered? If not, please explain why :-)
The commit id 71abbbf856a0e70 says that there are SOCs which could have
their target_residency and exit_latency values change at runtime. This
commit thus removed the ordering of the idle states according to their
target_residency/exit_latency. Adding Len and Arjan to the CC.
the ARM folks wanted a dynamic exit latency, so.... it makes much more
sense
to me to store the thing you want to use (exit latency) than the number
of the state.
more than that, you can order either by target residency OR by exit
latency,
if you sort by one, there is no guarantee that you're also sorted by the
other
IMO, it would be preferable to store the index for the moment as we are
integrating cpuidle with the scheduler. The index allows to access more
informations. Then when everything is fully integrated we can improve
the result, no ?
(for example, you can on a hardware level make a "fast exit" state, and
burn power for this faster exit,
which means your break even gets longer to recoup this extra power
compared to the same state without
the fast exit)
--
<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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/