[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201009290949.34245.trenn@suse.de>
Date: Wed, 29 Sep 2010 09:49:33 +0200
From: Thomas Renninger <trenn@...e.de>
To: Arjan van de Ven <arjan@...ux.intel.com>
Cc: "Rafael J. Wysocki" <rjw@...k.pl>,
Jean Pihet <jean.pihet@...oldbits.com>,
Ingo Molnar <mingo@...e.hu>,
Peter Zijlstra <peterz@...radead.org>,
Len Brown <len.brown@...el.com>, arjan@...radead.org,
Kevin Hilman <khilman@...prootsystems.com>,
linux-kernel@...r.kernel.org, linux-pm@...ts.linux-foundation.org,
linux-omap@...r.kernel.org, linux-perf-users@...r.kernel.org,
linux-trace-users@...r.kernel.org
Subject: Re: [PATCH] tracing, perf: add more power related events
On Tuesday 28 September 2010 23:45:24 Arjan van de Ven wrote:
> On 9/28/2010 2:22 PM, Rafael J. Wysocki wrote:
> > On Tuesday, September 28, 2010, Jean Pihet wrote:
> >> Hi,
> > Hi,
> >
> >> Here is what I am proposing, in reply to all your comments:
> >>
> >> 1) rename the events to match Thomas's proposal:
> >> power:power_cpu_cstate
> >> power:power_cpu_pstate
> >> power:power_cpu_sstate
I'd not name it that X86/ACPI specific.
power:processor_sleep
power:processor_frequency
power:system_suspend
This would map with X86/ACPI c/p/s states but the name would
also match fine with ARM and other archs.
> > If that sstate thing is going to mean "suspend", then please drop
> > it.
> > "Suspend" is not a state, let alone a CPU state. It is a procedure
> > by which the (entire) system is put into a sleep state (that is not
> > confined to CPUs).
>
> there are also non-suspend S states, like S0i1 and S0i3 (supported in
> the current Intel "Moorestown" platform)
>
> so it's slightly more complex than "just" suspend :)
Something specific for this arch could get introduced, similar as
Jean did for the ARM specifics, e.g.:
power:moorestown_suspend
Intel probably invented three names for this new technique, one
might fit as an event name?
Depending whether extra info needs passed through this event it
could also use
power:system_suspend
and pass a suspend state of #define S0i1 0x100, #define S0i2 0x101...
I try to find time to come up with another cleanup patch.
I also want to look at perf timechart then where I remember some ugly
hacks with C-state accounting and the broken state_start, state_end and
frequency_switch events. Hope it won't get too ugly and perf timechart
can support both, the old and the cleaned up events for a while.
Thomas
--
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