On Mon, Feb 28, 2011 at 4:49 PM, Pierre Tardy <tardyp@xxxxxxxxx> wrote: > On Mon, Feb 28, 2011 at 4:30 PM, Jean Pihet <jean.pihet@xxxxxxxxxxxxxx> wrote: >> Hi Pierre, >> >> On Mon, Feb 28, 2011 at 4:09 PM, Pierre Tardy <tardyp@xxxxxxxxx> wrote: >>> On Mon, Feb 28, 2011 at 2:43 PM, Vincent Guittot >>> <vincent.guittot@xxxxxxxxxx> wrote: >>>> On 27 February 2011 17:31, Pierre Tardy <tardyp@xxxxxxxxx> wrote: >>>>> On Fri, Feb 18, 2011 at 11:03 AM, Vincent Guittot >>>>> <vincent.guittot@xxxxxxxxxx> wrote: >>>>>> Hi, >>>>>> >>>>>> I have started to use the new cpuidle tracepoint and created a plugin >>>>>> for pytimechart. >>>>>> I'm not sure if it's the right way to add this cpuidle trace format >>>>>> update but it's the less intrusive one. >>>>> >>>>> Yes, it is okay. I actually plan to also put the whole cpuidle trace >>>>> handling into such plugin. >>>>> Would you care to send me one of your trace file, so that I can >>>>> actually test it. >>>> >>>> Yes, I have attached the trace file which is Vishwa's one in fact. >>> Thanks, I applied and pushed the patch. >>> >>> Please note that your trace has some suspicious tracepoints with same >>> timestamps for end of cpuidle and start of next cpuidle. >> That comes from a known problem about the timer on OMAP. The 32K timer >> is feeding the trace timestamps and so the granularity is not high >> enough (30us). > >>> 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. Thomas, can you help? [1] http://marc.info/?l=linux-omap&m=129439625501174&w=2 Jean > > Regards, > Pierre > -- 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
|