On Mon, Feb 28, 2011 at 9:36 PM, Jean Pihet <jean.pihet@xxxxxxxxxxxxxx> wrote: > 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. There is another patch for omap from santosh that adds description for each of the C states. https://patchwork.kernel.org/patch/549681/ Vishwa > > Thomas, can you help? > > [1] http://marc.info/?l=linux-omap&m=129439625501174&w=2 > > Jean > >> >> Regards, >> Pierre >> > > _______________________________________________ > linaro-dev mailing list > linaro-dev@xxxxxxxxxxxxxxxx > http://lists.linaro.org/mailman/listinfo/linaro-dev > -- 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
|