On 1/31/2014 7:37 AM, Daniel Lezcano wrote:
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 ?

more information, yes. but if the information isn't actually accurate (because 
it keeps changing
in the datastructure away from what it was for the cpu)... are you really 
achieving what you want?

on x86 I don't care; we don't actually change these dynamically much[1]. But if 
you have 1 or 2 things in mind to use,
I would suggest copying those 2 integers instead as we go, rather than the 
index.
Saves refcounting/locking etc etc nightmare as well on the other subsystems' 
datastructures..
... which you likely need to do to actually follow that index.



[1] Although in an ACPI world, the total number of C states can vary, for 
example it used to be quite common
that you got an extra C state on battery versus on wall power. This sort of 
dynamic thing requires refcounting
if more than the local cpuidle uses the data structures.

--
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/

Reply via email to