Re: [pytimechart] new cpuidle tracepoint

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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
>> 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.

> Thomas, can you help?
> [1]
> Jean
>> Regards,
>> Pierre
> _______________________________________________
> linaro-dev mailing list
> linaro-dev@xxxxxxxxxxxxxxxx
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

[Linux USB Development]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]    [Yosemite Photos]    [Free Online Dating]     [Linux Kernel]     [Linux SCSI]     [XFree86]

Add to Google Powered by Linux