Re: [PATCH V6 0/2] tracing, perf: cpu hotplug trace events

[Ingo Molnar <mingo@elte.hu>]

* Vincent Guittot <vincent.guittot@linaro.org> wrote:

> This patchset adds some tracepoints for tracing cpu state and for
> profiling the plug and unplug sequence.
> 
> Some SMP arm platform uses cpu hotplug feature for improving their
> power saving because they can go into their deepest idle state only in
> mono core mode. In addition, running into mono core mode makes the
> cpuidle job easier and more efficient which also results in the
> improvement of power saving of some use cases. As the plug state of a
> cpu can impact the cpuidle behavior, it's interesting to trace this
> state and to correlate it with cpuidle traces.
> Then, cpu hotplug is known to be an expensive operation which also
> takes a variable time depending of other processes' activity (from
> hundreds ms up to few seconds). These traces have shown that the arch
> part stays almost constant on arm platform whatever the cpu load is,
> whereas the plug duration increases.
> 
> ---
>  include/trace/events/cpu_hotplug.h |  103 ++++++++++++++++++++++++++++++++++++
>  kernel/cpu.c                       |   18 ++++++
>  2 files changed, 121 insertions(+), 0 deletions(-)
>  create mode 100644 include/trace/events/cpu_hotplug.h

Why not do something much simpler and fit these into the existing power:* events:

     power:cpu_idle
     power:cpu_frequency
     power:machine_suspend
     power:cpu_idle
     power:cpu_frequency
     power:machine_suspend

in an intelligent way?

CPU hotplug is really a 'soft' form of suspend and tools using power events could 
thus immediately use CPU hotplug events as well.

A suitable new 'state' value could be used to signal CPU hotplug events:

 enum {
        POWER_NONE = 0,
        POWER_CSTATE = 1,
        POWER_PSTATE = 2,
 };

POWER_HSTATE for hotplug-state, or so.

This would also express the design arguments that others have pointed out in the 
prior discussion: that CPU hotplug is really a power management variant, and that in 
the long run it could be done via regular idle as well. When that happens, the above 
unified event structure makes it all even simpler - analysis tools will just 
continue to work fine.

Thanks,

	Ingo