[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110302075625.GC15665@elte.hu>
Date: Wed, 2 Mar 2011 08:56:25 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Vincent Guittot <vincent.guittot@...aro.org>
Cc: linux-kernel@...r.kernel.org, linux-hotplug@...r.kernel.org,
fweisbec@...il.com, rostedt@...dmis.org, amit.kucheria@...aro.org,
rusty@...tcorp.com.au, tglx@...utronix.de,
Arjan van de Ven <arjan@...radead.org>,
Thomas Renninger <trenn@...e.de>,
Alan Cox <alan@...rguk.ukuu.org.uk>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
"H. Peter Anvin" <hpa@...or.com>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH V6 0/2] tracing, perf: cpu hotplug trace events
* Vincent Guittot <vincent.guittot@...aro.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists