[PATCH V2] tracing, perf : add cpu hotplug trace events

[PATCH V2] tracing, perf : add cpu hotplug trace events

[Vincent Guittot]

Please find below a new proposal for adding trace events for cpu hotplug.
The goal is to measure the latency of each part (kernel, architecture)
and also to trace the cpu hotplug activity with other power events. I
have tested these traces events on an arm platform.

Changes since previous version:
-Use cpu_hotplug for trace name
-Define traces for kernel core and arch parts only
-Use DECLARE_EVENT_CLASS and DEFINE_EVENT
-Use proper indentation

Subject: [PATCH] cpu hotplug tracepoint

this patch adds new events for cpu hotplug tracing
 * plug/unplug sequence
 * core and architecture latency measurements

Signed-off-by: Vincent Guittot <vincent.guittot@linaro.com>
---
 include/trace/events/cpu_hotplug.h |  117 ++++++++++++++++++++++++++++++++++++
 1 files changed, 117 insertions(+), 0 deletions(-)
 create mode 100644 include/trace/events/cpu_hotplug.h

diff --git a/include/trace/events/cpu_hotplug.h
b/include/trace/events/cpu_hotplug.h
new file mode 100644
index 0000000..efccc70
--- /dev/null
+++ b/include/trace/events/cpu_hotplug.h
@@ -0,0 +1,117 @@
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM cpu_hotplug
+
+#if !defined(_TRACE_CPU_HOTPLUG_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _TRACE_CPU_HOTPLUG_H
+
+#include <linux/tracepoint.h>
+
+DECLARE_EVENT_CLASS(cpu_hotplug,
+
+	TP_PROTO(unsigned int cpuid),
+
+	TP_ARGS(cpuid),
+
+	TP_STRUCT__entry(
+		__field(	unsigned int,	cpuid	)
+	),
+
+	TP_fast_assign(
+		__entry->cpuid = cpuid;
+	),
+
+	TP_printk("cpuid=%u", __entry->cpuid)
+);
+
+/* Core function of cpu hotplug */
+
+DEFINE_EVENT(cpu_hotplug, cpu_hotplug_down_start,
+
+	TP_PROTO(unsigned int cpuid),
+
+	TP_ARGS(cpuid)
+);
+
+DEFINE_EVENT(cpu_hotplug, cpu_hotplug_down_end,
+
+	TP_PROTO(unsigned int cpuid),
+
+	TP_ARGS(cpuid)
+);
+
+DEFINE_EVENT(cpu_hotplug, cpu_hotplug_up_start,
+
+	TP_PROTO(unsigned int cpuid),
+
+	TP_ARGS(cpuid)
+);
+
+DEFINE_EVENT(cpu_hotplug, cpu_hotplug_up_end,
+
+	TP_PROTO(unsigned int cpuid),
+
+	TP_ARGS(cpuid)
+);
+
+/* Architecture function for cpu hotplug */
+
+DEFINE_EVENT(cpu_hotplug, cpu_hotplug_arch_disable_start,
+
+	TP_PROTO(unsigned int cpuid),
+
+	TP_ARGS(cpuid)
+);
+
+DEFINE_EVENT(cpu_hotplug, cpu_hotplug_arch_disable_end,
+
+	TP_PROTO(unsigned int cpuid),
+
+	TP_ARGS(cpuid)
+);
+
+DEFINE_EVENT(cpu_hotplug, cpu_hotplug_arch_die_start,
+
+	TP_PROTO(unsigned int cpuid),
+
+	TP_ARGS(cpuid)
+);
+
+DEFINE_EVENT(cpu_hotplug, cpu_hotplug_arch_die_end,
+
+	TP_PROTO(unsigned int cpuid),
+
+	TP_ARGS(cpuid)
+);
+
+DEFINE_EVENT(cpu_hotplug, cpu_hotplug_arch_wait_die_start,
+
+	TP_PROTO(unsigned int cpuid),
+
+	TP_ARGS(cpuid)
+);
+
+DEFINE_EVENT(cpu_hotplug, cpu_hotplug_arch_wait_die_end,
+
+	TP_PROTO(unsigned int cpuid),
+
+	TP_ARGS(cpuid)
+);
+
+DEFINE_EVENT(cpu_hotplug, cpu_hotplug_arch_up_start,
+
+	TP_PROTO(unsigned int cpuid),
+
+	TP_ARGS(cpuid)
+);
+
+DEFINE_EVENT(cpu_hotplug, cpu_hotplug_arch_up_end,
+
+	TP_PROTO(unsigned int cpuid),
+
+	TP_ARGS(cpuid)
+);
+
+#endif /* _TRACE_CPU_HOTPLUG_H */
+
+/* This part must be outside protection */
+#include <trace/define_trace.h>
-- 
1.7.1

Re: [PATCH V2] tracing, perf : add cpu hotplug trace events

[Frederic Weisbecker]

On Thu, Jan 20, 2011 at 09:25:54AM +0100, Vincent Guittot wrote:
> Please find below a new proposal for adding trace events for cpu hotplug.
> The goal is to measure the latency of each part (kernel, architecture)
> and also to trace the cpu hotplug activity with other power events. I
> have tested these traces events on an arm platform.
> 
> Changes since previous version:
> -Use cpu_hotplug for trace name
> -Define traces for kernel core and arch parts only
> -Use DECLARE_EVENT_CLASS and DEFINE_EVENT
> -Use proper indentation
> 
> Subject: [PATCH] cpu hotplug tracepoint
> 
> this patch adds new events for cpu hotplug tracing
>  * plug/unplug sequence
>  * core and architecture latency measurements
> 
> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.com>
> ---
>  include/trace/events/cpu_hotplug.h |  117 ++++++++++++++++++++++++++++++++++++

Note we can't apply new tracepoints if they are not inserted in the code.

> +DEFINE_EVENT(cpu_hotplug, cpu_hotplug_arch_wait_die_start,
> +
> +	TP_PROTO(unsigned int cpuid),
> +
> +	TP_ARGS(cpuid)
> +);
> +
> +DEFINE_EVENT(cpu_hotplug, cpu_hotplug_arch_wait_die_end,
> +
> +	TP_PROTO(unsigned int cpuid),
> +
> +	TP_ARGS(cpuid)
> +);

What is wait die, compared to die for example?

We need those tracepoints to be applied to get that reviewable in practice.

Thanks.

Re: [PATCH V2] tracing, perf : add cpu hotplug trace events

[Vincent Guittot]

On 20 January 2011 17:11, Frederic Weisbecker <fweisbec@gmail.com> wrote:
> On Thu, Jan 20, 2011 at 09:25:54AM +0100, Vincent Guittot wrote:
>> Please find below a new proposal for adding trace events for cpu hotplug.
>> The goal is to measure the latency of each part (kernel, architecture)
>> and also to trace the cpu hotplug activity with other power events. I
>> have tested these traces events on an arm platform.
>>
>> Changes since previous version:
>> -Use cpu_hotplug for trace name
>> -Define traces for kernel core and arch parts only
>> -Use DECLARE_EVENT_CLASS and DEFINE_EVENT
>> -Use proper indentation
>>
>> Subject: [PATCH] cpu hotplug tracepoint
>>
>> this patch adds new events for cpu hotplug tracing
>>  * plug/unplug sequence
>>  * core and architecture latency measurements
>>
>> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.com>
>> ---
>>  include/trace/events/cpu_hotplug.h |  117 ++++++++++++++++++++++++++++++++++++
>
> Note we can't apply new tracepoints if they are not inserted in the code.

I agree, i just want to have 1st feedbacks on the tracepoint interface
before providing a patch which inserts the trace in the code.

>
>> +DEFINE_EVENT(cpu_hotplug, cpu_hotplug_arch_wait_die_start,
>> +
>> +     TP_PROTO(unsigned int cpuid),
>> +
>> +     TP_ARGS(cpuid)
>> +);
>> +
>> +DEFINE_EVENT(cpu_hotplug, cpu_hotplug_arch_wait_die_end,
>> +
>> +     TP_PROTO(unsigned int cpuid),
>> +
>> +     TP_ARGS(cpuid)
>> +);
>
> What is wait die, compared to die for example?
>

The arch_wait_die is used to trace the process which waits for the cpu
to die (__cpu_die) and the arch_die is used to trace when the cpu dies
(cpu_die)

> We need those tracepoints to be applied to get that reviewable in practice.
>

Ok, I'm going to send a proposal

> Thanks.
>

Re: [PATCH V2] tracing, perf : add cpu hotplug trace events

[Frederic Weisbecker]

On Fri, Jan 21, 2011 at 09:43:18AM +0100, Vincent Guittot wrote:
> On 20 January 2011 17:11, Frederic Weisbecker <fweisbec@gmail.com> wrote:
> > On Thu, Jan 20, 2011 at 09:25:54AM +0100, Vincent Guittot wrote:
> >> Please find below a new proposal for adding trace events for cpu hotplug.
> >> The goal is to measure the latency of each part (kernel, architecture)
> >> and also to trace the cpu hotplug activity with other power events. I
> >> have tested these traces events on an arm platform.
> >>
> >> Changes since previous version:
> >> -Use cpu_hotplug for trace name
> >> -Define traces for kernel core and arch parts only
> >> -Use DECLARE_EVENT_CLASS and DEFINE_EVENT
> >> -Use proper indentation
> >>
> >> Subject: [PATCH] cpu hotplug tracepoint
> >>
> >> this patch adds new events for cpu hotplug tracing
> >>  * plug/unplug sequence
> >>  * core and architecture latency measurements
> >>
> >> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.com>
> >> ---
> >>  include/trace/events/cpu_hotplug.h |  117 ++++++++++++++++++++++++++++++++++++
> >
> > Note we can't apply new tracepoints if they are not inserted in the code.
> 
> I agree, i just want to have 1st feedbacks on the tracepoint interface
> before providing a patch which inserts the trace in the code.
> 
> >
> >> +DEFINE_EVENT(cpu_hotplug, cpu_hotplug_arch_wait_die_start,
> >> +
> >> +     TP_PROTO(unsigned int cpuid),
> >> +
> >> +     TP_ARGS(cpuid)
> >> +);
> >> +
> >> +DEFINE_EVENT(cpu_hotplug, cpu_hotplug_arch_wait_die_end,
> >> +
> >> +     TP_PROTO(unsigned int cpuid),
> >> +
> >> +     TP_ARGS(cpuid)
> >> +);
> >
> > What is wait die, compared to die for example?
> >
> 
> The arch_wait_die is used to trace the process which waits for the cpu
> to die (__cpu_die) and the arch_die is used to trace when the cpu dies
> (cpu_die)

I still can't find the difference.

Having:

trace_cpu_hotplug_arch_die_start(cpu)
__cpu_die();
trace_cpu_hotplug_arch_die_end(cpu)

Is not enough to get both the information that a cpu dies
and the time took to do so?

Re: [PATCH V2] tracing, perf : add cpu hotplug trace events

[Steven Rostedt]

On Fri, 2011-01-21 at 09:43 +0100, Vincent Guittot wrote:
> On 20 January 2011 17:11, Frederic Weisbecker <fweisbec@gmail.com> wrote:

> >
> >> +DEFINE_EVENT(cpu_hotplug, cpu_hotplug_arch_wait_die_start,
> >> +
> >> +     TP_PROTO(unsigned int cpuid),
> >> +
> >> +     TP_ARGS(cpuid)
> >> +);
> >> +
> >> +DEFINE_EVENT(cpu_hotplug, cpu_hotplug_arch_wait_die_end,
> >> +
> >> +     TP_PROTO(unsigned int cpuid),
> >> +
> >> +     TP_ARGS(cpuid)
> >> +);
> >
> > What is wait die, compared to die for example?
> >
> 
> The arch_wait_die is used to trace the process which waits for the cpu
> to die (__cpu_die) and the arch_die is used to trace when the cpu dies
> (cpu_die)

Shouldn't that be "cpu_hotplug_arch_task_wait_die" then? If it is a task
that is waiting?

-- Steve

> 
> > We need those tracepoints to be applied to get that reviewable in practice.
> >
> 
> Ok, I'm going to send a proposal
> 
> > Thanks.
> >

Re: [PATCH V2] tracing, perf : add cpu hotplug trace events

[Vincent Guittot]

On 21 January 2011 17:44, Frederic Weisbecker <fweisbec@gmail.com> wrote:
> On Fri, Jan 21, 2011 at 09:43:18AM +0100, Vincent Guittot wrote:
>> On 20 January 2011 17:11, Frederic Weisbecker <fweisbec@gmail.com> wrote:
>> > On Thu, Jan 20, 2011 at 09:25:54AM +0100, Vincent Guittot wrote:
>> >> Please find below a new proposal for adding trace events for cpu hotplug.
>> >> The goal is to measure the latency of each part (kernel, architecture)
>> >> and also to trace the cpu hotplug activity with other power events. I
>> >> have tested these traces events on an arm platform.
>> >>
>> >> Changes since previous version:
>> >> -Use cpu_hotplug for trace name
>> >> -Define traces for kernel core and arch parts only
>> >> -Use DECLARE_EVENT_CLASS and DEFINE_EVENT
>> >> -Use proper indentation
>> >>
>> >> Subject: [PATCH] cpu hotplug tracepoint
>> >>
>> >> this patch adds new events for cpu hotplug tracing
>> >>  * plug/unplug sequence
>> >>  * core and architecture latency measurements
>> >>
>> >> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.com>
>> >> ---
>> >>  include/trace/events/cpu_hotplug.h |  117 ++++++++++++++++++++++++++++++++++++
>> >
>> > Note we can't apply new tracepoints if they are not inserted in the code.
>>
>> I agree, i just want to have 1st feedbacks on the tracepoint interface
>> before providing a patch which inserts the trace in the code.
>>
>> >
>> >> +DEFINE_EVENT(cpu_hotplug, cpu_hotplug_arch_wait_die_start,
>> >> +
>> >> +     TP_PROTO(unsigned int cpuid),
>> >> +
>> >> +     TP_ARGS(cpuid)
>> >> +);
>> >> +
>> >> +DEFINE_EVENT(cpu_hotplug, cpu_hotplug_arch_wait_die_end,
>> >> +
>> >> +     TP_PROTO(unsigned int cpuid),
>> >> +
>> >> +     TP_ARGS(cpuid)
>> >> +);
>> >
>> > What is wait die, compared to die for example?
>> >
>>
>> The arch_wait_die is used to trace the process which waits for the cpu
>> to die (__cpu_die) and the arch_die is used to trace when the cpu dies
>> (cpu_die)
>
> I still can't find the difference.
>
> Having:
>
> trace_cpu_hotplug_arch_die_start(cpu)
> __cpu_die();
> trace_cpu_hotplug_arch_die_end(cpu)
>
> Is not enough to get both the information that a cpu dies
> and the time took to do so?
>

it's quite interesting to trace the cpu_die function because the cpu
really dies in this one. The __cpu_die function can't return if the
cpu fails to die in the very last step and then wake up. But this
could be detected with some cpu_die traces.

for a normal use case we have something like :
cpu 0 enters __cpu_die
cpu 1 enters cpu_die
cpu1 acks that it is going to died
cpu0 returns from __cpu_die

if the cpu 1 fails to die at the very last step, we could have:
cpu 0 enters __cpu_die
cpu 1 enters cpu_idle --> cpu_die
cpu1 leaves cpu_die because of some issues and comes back into cpu_idle.
cpu0 returns from __cpu_die after a timeout or an error ack

Then, cpu_die traces can be used with power traces for profiling the
cpu power state. May be, the power.h trace file is a better place for
the cpu_die traces ?

Re: [PATCH V2] tracing, perf : add cpu hotplug trace events

[Frederic Weisbecker]

On Fri, Jan 21, 2011 at 06:41:58PM +0100, Vincent Guittot wrote:
> On 21 January 2011 17:44, Frederic Weisbecker <fweisbec@gmail.com> wrote:
> > On Fri, Jan 21, 2011 at 09:43:18AM +0100, Vincent Guittot wrote:
> >> On 20 January 2011 17:11, Frederic Weisbecker <fweisbec@gmail.com> wrote:
> >> > On Thu, Jan 20, 2011 at 09:25:54AM +0100, Vincent Guittot wrote:
> >> >> Please find below a new proposal for adding trace events for cpu hotplug.
> >> >> The goal is to measure the latency of each part (kernel, architecture)
> >> >> and also to trace the cpu hotplug activity with other power events. I
> >> >> have tested these traces events on an arm platform.
> >> >>
> >> >> Changes since previous version:
> >> >> -Use cpu_hotplug for trace name
> >> >> -Define traces for kernel core and arch parts only
> >> >> -Use DECLARE_EVENT_CLASS and DEFINE_EVENT
> >> >> -Use proper indentation
> >> >>
> >> >> Subject: [PATCH] cpu hotplug tracepoint
> >> >>
> >> >> this patch adds new events for cpu hotplug tracing
> >> >>  * plug/unplug sequence
> >> >>  * core and architecture latency measurements
> >> >>
> >> >> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.com>
> >> >> ---
> >> >>  include/trace/events/cpu_hotplug.h |  117 ++++++++++++++++++++++++++++++++++++
> >> >
> >> > Note we can't apply new tracepoints if they are not inserted in the code.
> >>
> >> I agree, i just want to have 1st feedbacks on the tracepoint interface
> >> before providing a patch which inserts the trace in the code.
> >>
> >> >
> >> >> +DEFINE_EVENT(cpu_hotplug, cpu_hotplug_arch_wait_die_start,
> >> >> +
> >> >> +     TP_PROTO(unsigned int cpuid),
> >> >> +
> >> >> +     TP_ARGS(cpuid)
> >> >> +);
> >> >> +
> >> >> +DEFINE_EVENT(cpu_hotplug, cpu_hotplug_arch_wait_die_end,
> >> >> +
> >> >> +     TP_PROTO(unsigned int cpuid),
> >> >> +
> >> >> +     TP_ARGS(cpuid)
> >> >> +);
> >> >
> >> > What is wait die, compared to die for example?
> >> >
> >>
> >> The arch_wait_die is used to trace the process which waits for the cpu
> >> to die (__cpu_die) and the arch_die is used to trace when the cpu dies
> >> (cpu_die)
> >
> > I still can't find the difference.
> >
> > Having:
> >
> > trace_cpu_hotplug_arch_die_start(cpu)
> > __cpu_die();
> > trace_cpu_hotplug_arch_die_end(cpu)
> >
> > Is not enough to get both the information that a cpu dies
> > and the time took to do so?
> >
> 
> it's quite interesting to trace the cpu_die function because the cpu
> really dies in this one.

Note in case of success, you have barely the same time between die and
wait_die, the difference will reside in some completion wait/polling,
noise, mostly. Probably most of the time unnoticeable and irrelevant.

Plus if you opt for this scheme, you need to put your die hook into
every architectures, while otherwise a simple trace_cpu_die_start()
trace_cpu_die_stop() pair around __cpu_die() call in the generic code
is enough.

> The __cpu_die function can't return if the
> cpu fails to die in the very last step and then wake up. But this
> could be detected with some cpu_die traces.
>
> 
> for a normal use case we have something like :
> cpu 0 enters __cpu_die
> cpu 1 enters cpu_die
> cpu1 acks that it is going to died
> cpu0 returns from __cpu_die
> 
> if the cpu 1 fails to die at the very last step, we could have:
> cpu 0 enters __cpu_die
> cpu 1 enters cpu_idle --> cpu_die
> cpu1 leaves cpu_die because of some issues and comes back into cpu_idle.
> cpu0 returns from __cpu_die after a timeout or an error ack

If it fails in the hardware level, you'll certainly notice in your
power profiling because a CPU is not supposed to take seconds to
die. Especially with a such visual tool like pytimechart, it will
be obvious.

For the details, that's something that must be found in syslogs and
that's it.

I don't think it's a good idea to handle such buggy and unexpected case at
the tracepoint level. You don't want to profile bugs, you want to debug them.
So it doesn't belong to this space IMHO.

> Then, cpu_die traces can be used with power traces for profiling the
> cpu power state. May be, the power.h trace file is a better place for
> the cpu_die traces ?

Hmm, this should probably stay inside the cpu hotplug tracepoint family,
this is where people will seek them in the first place.

Re: [PATCH V2] tracing, perf : add cpu hotplug trace events

[Vincent Guittot]

On 22 January 2011 03:42, Frederic Weisbecker <fweisbec@gmail.com> wrote:
> On Fri, Jan 21, 2011 at 06:41:58PM +0100, Vincent Guittot wrote:
>> On 21 January 2011 17:44, Frederic Weisbecker <fweisbec@gmail.com> wrote:
>> > On Fri, Jan 21, 2011 at 09:43:18AM +0100, Vincent Guittot wrote:
>> >> On 20 January 2011 17:11, Frederic Weisbecker <fweisbec@gmail.com> wrote:
>> >> > On Thu, Jan 20, 2011 at 09:25:54AM +0100, Vincent Guittot wrote:
>> >> >> Please find below a new proposal for adding trace events for cpu hotplug.
>> >> >> The goal is to measure the latency of each part (kernel, architecture)
>> >> >> and also to trace the cpu hotplug activity with other power events. I
>> >> >> have tested these traces events on an arm platform.
>> >> >>
>> >> >> Changes since previous version:
>> >> >> -Use cpu_hotplug for trace name
>> >> >> -Define traces for kernel core and arch parts only
>> >> >> -Use DECLARE_EVENT_CLASS and DEFINE_EVENT
>> >> >> -Use proper indentation
>> >> >>
>> >> >> Subject: [PATCH] cpu hotplug tracepoint
>> >> >>
>> >> >> this patch adds new events for cpu hotplug tracing
>> >> >>  * plug/unplug sequence
>> >> >>  * core and architecture latency measurements
>> >> >>
>> >> >> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.com>
>> >> >> ---
>> >> >>  include/trace/events/cpu_hotplug.h |  117 ++++++++++++++++++++++++++++++++++++
>> >> >
>> >> > Note we can't apply new tracepoints if they are not inserted in the code.
>> >>
>> >> I agree, i just want to have 1st feedbacks on the tracepoint interface
>> >> before providing a patch which inserts the trace in the code.
>> >>
>> >> >
>> >> >> +DEFINE_EVENT(cpu_hotplug, cpu_hotplug_arch_wait_die_start,
>> >> >> +
>> >> >> +     TP_PROTO(unsigned int cpuid),
>> >> >> +
>> >> >> +     TP_ARGS(cpuid)
>> >> >> +);
>> >> >> +
>> >> >> +DEFINE_EVENT(cpu_hotplug, cpu_hotplug_arch_wait_die_end,
>> >> >> +
>> >> >> +     TP_PROTO(unsigned int cpuid),
>> >> >> +
>> >> >> +     TP_ARGS(cpuid)
>> >> >> +);
>> >> >
>> >> > What is wait die, compared to die for example?
>> >> >
>> >>
>> >> The arch_wait_die is used to trace the process which waits for the cpu
>> >> to die (__cpu_die) and the arch_die is used to trace when the cpu dies
>> >> (cpu_die)
>> >
>> > I still can't find the difference.
>> >
>> > Having:
>> >
>> > trace_cpu_hotplug_arch_die_start(cpu)
>> > __cpu_die();
>> > trace_cpu_hotplug_arch_die_end(cpu)
>> >
>> > Is not enough to get both the information that a cpu dies
>> > and the time took to do so?
>> >
>>
>> it's quite interesting to trace the cpu_die function because the cpu
>> really dies in this one.
>
> Note in case of success, you have barely the same time between die and
> wait_die, the difference will reside in some completion wait/polling,
> noise, mostly. Probably most of the time unnoticeable and irrelevant.
>

OK, tracing only __cpu_die should be enough

> Plus if you opt for this scheme, you need to put your die hook into
> every architectures, while otherwise a simple trace_cpu_die_start()
> trace_cpu_die_stop() pair around __cpu_die() call in the generic code
> is enough.
>
>> The __cpu_die function can't return if the
>> cpu fails to die in the very last step and then wake up. But this
>> could be detected with some cpu_die traces.
>>
>>
>> for a normal use case we have something like :
>> cpu 0 enters __cpu_die
>> cpu 1 enters cpu_die
>> cpu1 acks that it is going to died
>> cpu0 returns from __cpu_die
>>
>> if the cpu 1 fails to die at the very last step, we could have:
>> cpu 0 enters __cpu_die
>> cpu 1 enters cpu_idle --> cpu_die
>> cpu1 leaves cpu_die because of some issues and comes back into cpu_idle.
>> cpu0 returns from __cpu_die after a timeout or an error ack
>
> If it fails in the hardware level, you'll certainly notice in your
> power profiling because a CPU is not supposed to take seconds to
> die. Especially with a such visual tool like pytimechart, it will
> be obvious.
>
> For the details, that's something that must be found in syslogs and
> that's it.
>
> I don't think it's a good idea to handle such buggy and unexpected case at
> the tracepoint level. You don't want to profile bugs, you want to debug them.
> So it doesn't belong to this space IMHO.
>
>> Then, cpu_die traces can be used with power traces for profiling the
>> cpu power state. May be, the power.h trace file is a better place for
>> the cpu_die traces ?
>
> Hmm, this should probably stay inside the cpu hotplug tracepoint family,
> this is where people will seek them in the first place.
>