On Fri, 30 Mar 2007 01:05:59 PDT, Andrew Morton said: > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm3/
Somebody is confused (possibly me). Running an x86_64 kernel, and I have: % cat /proc/acpi/processor/CPU0/power active state: C0 max_cstate: C8 bus master activity: 00000000 maximum allowed latency: 2000 usec states: C1: type[C1] promotion[--] demotion[--] latency[001] usage[00000003] duration[00000000000000000000] C2: type[C2] promotion[--] demotion[--] latency[001] usage[00166266] duration[00000000000000000000] C3: type[C3] promotion[--] demotion[--] latency[057] usage[02045938] duration[00000000000000000000] Wow. Lots of zeros in that last column.. The 'duration' is output by this code in drivers/acpi/processor_idle.c that thinks the value is an 'unsigned long long': seq_printf(seq, "latency[%03d] usage[%08d] duration[%020llu]\n", pr->power.states[i].latency, pr->power.states[i].usage, (unsigned long long)pr->power.states[i].time); However, over in /sys, we have non-zero values for the usage/time: % cat /sys/devices/system/cpu/cpu0/cpuidle/state?/time 0 110861364 -2091818383 That's because in drivers/cpuidle/sysfs.c, we have this code that thinks a %d is suitable to output that number: #define define_show_state_function(_name) static ssize_t show_state_##_name(struct cpuidle_state *state, char *buf) { \ return sprintf(buf, "%d\n", state->_name);\ } ... define_one_state_ro(time, show_state_time); But the negative number for state2/time indicates that *this* isn't right either....
pgpaOEE2DI6LX.pgp
Description: PGP signature