Hi,
sorry for the late reply...
On Monday 28 February 2011 17:52:23 Vishwanath Sripathy wrote:
On Mon, Feb 28, 2011 at 9:36 PM, Jean Pihet jean.pihet@newoldbits.com wrote:
...
Also, cpuidle states name in pytimechart are very selfishly hardcoded with intel's convention. Can you tell what is your convention, so that we can think of a best way to handle display of state's name for ftrace text output?
The power trace points API is described in Documentation/trace/events-power.txt. i.e. trace_cpu_idle(4, smp_processor_id()) means that the system enters the idle state 4, while trace_cpu_idle(PWR_EVENT_EXIT, smp_processor_id())
Yes, I know this.
This state is depending on the cpuidle state table. on Intel arch, some CStates are reserved and unimplemented. thus the same of the Cstate does not correspond to the id of the cpuidle state. e.g. 0 -> C0 (not an idle state, in IA) 1 -> C1 2 -> C2 3 -> C4 4 -> C6 5 -> S0i1 ( a platform idle state) 6 -> S0i3 ( another deeper platform idle state) This is reflected in the table (I just moved this table in cpuidle.py): c_state_table = ["C0","C1","C2","C4","C6","S0i1","S0i3"]
So.. beware! cpuidle id 3 will currently be displayed as "C4" in pytimechart, which is what *intel_mid* guys want, but probably not what OMAP guys want.
Ok sorry I misunterstood the point.
The cpuidle state names are usually available on sysfs. perf and trace-cmd are dumping this in their binary format, but ftrace text interface is not. So this has to be hardcoded or configured.
We could add the state name (or abbr) in the ftrace format but that requires some generic kernel changes (again).
Thomas (added in the To: list) attempted to introduce some abbreviated states names but I do not know if this went through to the mainline and if it is applicable to pytimechart. Cf. [1] for the patch.
My patch was not accepted: http://www.spinics.net/lists/linux-omap/msg43800.html http://www.spinics.net/lists/linux-omap/msg43824.html
Instead I sent another one correcting the "not that fortunate" idle state naming in the intel_idle driver: https://patchwork.kernel.org/patch/593701
I also had preferred the .abbr solution. I have another tool reading out c-state names and there I correct the NHM-Cx into Cx-NHM and then I cut off the rest (utils/idle_monitor/cpuidle_sysfs.c in fix_up_intel_idle_driver_name())
And now we are at the reason for my late reply :) This tools should be arch independent and also provide some worthy info on arm. It would be great if someone can give it a quick test. I test compiled it on ppc64, but there the cpuidle framework patches did not make it into the kernel yet and I do not have an arm system.
It's hosted here: git clone git://gitorious.org/cpupowerutils/cpupowerutils.git
git branch --track cpupowerutils origin/cpupowerutils git checkout cpupowerutils make
For some reason I need another make call, so that translation succeeds, but you can ignore it, if you should see a xgettext message.
cpupower frequency-set/frequency-info are the same as cpufreq-set/cpufreq-info which you might know.
New is and there you should see some info on a cpuidle supporting system: cpupower idle-info
cpupower monitor -l cpupower monitor
I hope you come that far...
The tool also implements reading out some registers on X86 to retrieve the actual residency time in C-states from HW. This can easily get added for ARM or other archs as well, but I've heard such registers do not exist on ARM?
Thomas