Hi Peter, On 01/31/2014 02:32 PM, Peter Zijlstra wrote: > On Fri, Jan 31, 2014 at 02:15:47PM +0530, Preeti Murthy wrote: >>> >>> If the driver does its own random mapping that will break the governor >>> logic. So yes, the states are ordered, the higher the index is, the more you >>> save power and the higher the exit latency is. >> >> The above point holds true for only the ladder governor which sees the idle >> states indexed in the increasing order of target_residency/exit_latency. >> >> However this is not true as far as I can see in the menu governor. It >> acknowledges the dynamic ordering of idle states as can be seen in the >> menu_select() function in the menu governor, where the idle state for the >> CPU gets chosen. You will notice that, even if it is found that the >> predicted >> idle time of the CPU is smaller than the target residency of an idle state, >> the governor continues to search for suitable idle states in the higher >> indexed >> states although it should have halted if the idle states' were ordered >> according >> to their target residency.. The same holds for exit_latency. >> >> 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. Thanks Regards Preeti U Murthy > -- 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/
