On 10/25/2010 5:55 AM, Thomas Renninger wrote:
But the actual code does not actually deal with any 'state 0', does it?
It does. Not being idle is tracked by cpuidle driver as state 0
(arch independent):
/sys/devices/system/cpu/cpu0/cpuidle/state0/
halt/C1 on X86 is:
/sys/devices/system/cpu/cpu0/cpuidle/state1/
...
state0 is still OS idle!
the API is just weird for this, from a userspace perspective
if the kernel picks this state 0 for the idle handler, the userspace app
gets
two events
one for going to state 0 to enter the idle state
one for going to state 0 to exit idle
but they're the exact same event in your API.
rather unpleasant from a userspace program perspective....
now I need to start tracking even more state on top in powertop to be
able to make a guess at which of the two meanings a state 0 entry has.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
