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@xxxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-trace-users" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
|