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
If that sstate thing is going to mean suspend, then please drop it.
Suspend is not a
Hi,
On Wed, Sep 29, 2010 at 9:49 AM, Thomas Renninger tr...@suse.de wrote:
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
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
...
2) introduce a new Kconfig option CONFIG_DEPRECATED_POWER_EVENTS and
conditionally map a subset
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
If that sstate thing is going to mean
Hi,
On Tue, Sep 28, 2010 at 11:22 PM, Rafael J. Wysocki r...@sisk.pl 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
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
On Tuesday, September 28, 2010, 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:
On Tuesday, September 28, 2010, Jean Pihet wrote:
Hi,
On Tue, Sep 28, 2010 at 11:22 PM, Rafael J. Wysocki r...@sisk.pl 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
Hi,
Here is a patch that redefines the power events API. The advantages
are: easier maintainance of the kernel and the
user space tools, a cleaner and more generic interface, more
parameters for fine tracing and even documentation!
Thomas, this patch has your patch above merged in ('power-trace:
On 9/22/2010 8:31 AM, Jean Pihet wrote:
Hi,
Here is a patch that redefines the power events API. The advantages
are: easier maintainance of the kernel and the
user space tools, a cleaner and more generic interface, more
parameters for fine tracing and even documentation!
Thomas, this patch
On Wed, Sep 22, 2010 at 5:33 PM, Arjan van de Ven ar...@linux.intel.com wrote:
On 9/22/2010 8:31 AM, Jean Pihet wrote:
Hi,
Here is a patch that redefines the power events API. The advantages
are: easier maintainance of the kernel and the
user space tools, a cleaner and more generic
On 9/22/2010 8:36 AM, Jean Pihet wrote:
On Wed, Sep 22, 2010 at 5:33 PM, Arjan van de Venar...@linux.intel.com wrote:
On 9/22/2010 8:31 AM, Jean Pihet wrote:
Hi,
Here is a patch that redefines the power events API. The advantages
are: easier maintainance of the kernel and the
user space
On Wed, 2010-09-22 at 09:32 -0700, Arjan van de Ven wrote:
What are the apps that are using it? I know about builtin-timechart,
pytimechart. Is powertop using this as well?
powertop 2.x codebase is as well.
and a bunch of tools we have internal here at Intel.
the thing with ABIs is
On Wed, 2010-09-22 at 09:32 -0700, Arjan van de Ven wrote:
Also, please don't cross-post to subscriber only lists, that's annoying
as hell.
(removed the disc...@lesswatts list)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
On 9/22/2010 9:43 AM, Peter Zijlstra wrote:
On Wed, 2010-09-22 at 09:32 -0700, Arjan van de Ven wrote:
What are the apps that are using it? I know about builtin-timechart,
pytimechart. Is powertop using this as well?
powertop 2.x codebase is as well.
and a bunch of tools we have internal
On Wed, 2010-09-22 at 10:06 -0700, Arjan van de Ven wrote:
In this case we're talking about basically a suprious rename of
something that isn't really an improvement
(because it makes it harder to subscribe to only one type of event)...
that's not a good thing.
People have been talking
On Wednesday 22 September 2010 19:06:54 Arjan van de Ven wrote:
On 9/22/2010 9:43 AM, Peter Zijlstra wrote:
On Wed, 2010-09-22 at 09:32 -0700, Arjan van de Ven wrote:
What are the apps that are using it? I know about builtin-timechart,
pytimechart. Is powertop using this as well?
On Wednesday, September 22, 2010, Arjan van de Ven wrote:
On 9/22/2010 8:31 AM, Jean Pihet wrote:
Hi,
Here is a patch that redefines the power events API. The advantages
are: easier maintainance of the kernel and the
user space tools, a cleaner and more generic interface, more
On 9/22/2010 10:57 AM, Thomas Renninger wrote:
On Wed
unfortunately this code is changing a userspace ABI... we really
shouldn't do that if we can avoid it,
and here we can avoid it.
[do you really need to get personal?]
Wow, this is your first post on this thread
it isn't.
(but I've
On Wed, 2010-09-22 at 19:30 +0200, Peter Zijlstra wrote:
On Wed, 2010-09-22 at 10:06 -0700, Arjan van de Ven wrote:
That said, I really didn't read this discussion much, but your stance
seems to be that any tracepoint you use must stay valid, and I object to
that.
We could add a
* Steven Rostedt rost...@goodmis.org wrote:
We could add a TRACE_EVENT_ABI() as Ingo has been suggesting. [...]
That would be rather useful.
We could still be flexible about experimental tracepoints (they dont
hurt), but apps should stick to ABI bits - or at least not complain when
non-ABI
On Wed, 2010-09-22 at 14:15 -0400, Steven Rostedt wrote:
On Wed, 2010-09-22 at 19:30 +0200, Peter Zijlstra wrote:
On Wed, 2010-09-22 at 10:06 -0700, Arjan van de Ven wrote:
That said, I really didn't read this discussion much, but your stance
seems to be that any tracepoint you use
On Wed, 2010-09-22 at 20:26 +0200, Peter Zijlstra wrote:
On Wed, 2010-09-22 at 14:15 -0400, Steven Rostedt wrote:
On Wed, 2010-09-22 at 19:30 +0200, Peter Zijlstra wrote:
On Wed, 2010-09-22 at 10:06 -0700, Arjan van de Ven wrote:
That said, I really didn't read this discussion
On Wed, 2010-09-22 at 14:36 -0400, Steven Rostedt wrote:
I still don't see why you need TRACE_EVENT_ABI for that, if its the same
name and the format can be extended you get the same results with what
we've got. Apps need to read/parse the format thing anyway.
Just a marker that these
[Dropping disc...@lesswatts.org from the CC list.]
On Wednesday, September 22, 2010, Jean Pihet wrote:
Hi,
Here is a patch that redefines the power events API. The advantages
are: easier maintainance of the kernel and the
user space tools, a cleaner and more generic interface, more
Hi -
On Wed, Sep 22, 2010 at 08:26:40PM +0200, Peter Zijlstra wrote:
[...]
Not sure what you mean by double tracepoints
Two different tracepoints in the same location.
Another possibility may be to provide a backward-compatibility module
that maps new tracepoints to old ones. On demand, it
Hi,
I had a quick look at this and it's amazing how broken
the whole power event tracing interfaces are.
It's not your fault, Jean, they always were and adding your stuff is
fine.
Some questions, maybe I've overseen something:
Why does this event:
DEFINE_EVENT(power, power_frequency,
exist and
Hi Thomas,
On Fri, Sep 17, 2010 at 3:08 PM, Thomas Renninger tr...@suse.de wrote:
Hi,
I had a quick look at this and it's amazing how broken
the whole power event tracing interfaces are.
It's not your fault, Jean, they always were and adding your stuff is
fine.
That is the whole point! This
* Jean Pihet jean.pi...@newoldbits.com wrote:
Apropos documentation..., are the power trace events documented
somewhere?
No. We need something like Documentation/trace/events-kmem.txt. I can
write that with for the new power API.
Such a patch introducing events-power.txt would be most
On Friday 17 September 2010 16:05:51 Jean Pihet wrote:
Hi Thomas,
On Fri, Sep 17, 2010 at 3:08 PM, Thomas Renninger tr...@suse.de wrote:
Hi,
I had a quick look at this and it's amazing how broken
the whole power event tracing interfaces are.
It's not your fault, Jean, they always
On Friday 17 September 2010 16:24:59 Ingo Molnar wrote:
* Jean Pihet jean.pi...@newoldbits.com wrote:
Apropos documentation..., are the power trace events documented
somewhere?
No. We need something like Documentation/trace/events-kmem.txt. I
can write that with for the new power
* Thomas Renninger tr...@suse.de wrote:
On Friday 17 September 2010 16:24:59 Ingo Molnar wrote:
* Jean Pihet jean.pi...@newoldbits.com wrote:
Apropos documentation..., are the power trace events documented
somewhere?
No. We need something like
Some patches for cleanup...
compile tested only...
Should not break existing user space apps, but they should
get converted asap to use power_swtich_state...
---
power-trace: Rename power frequency to power_switch_state
this interface/function is not intended for frequency changes
only, but
power-trace: Use power_switch_state instead of power_start and power_end
No need to have power_start and power_end. power_switch_state of state=0
means we exited power saving state. Userspace has all the information
it needs to detect power enter/exit case.
Export it, so that intel_idle can make
power-trace: Add x86 ACPI S- (machine sleep) state events.
Signed-off-by: Thomas Renninger tr...@suse.de
---
drivers/acpi/sleep.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
Index: linux-2.6.35-master/drivers/acpi/sleep.c
DO NOT APPLY THIS ONE!!!
The others should go into a mainline tree if Jean is ok with them.
This one does not work, due to some include dependencies or whatever
else I can't see right now.
The idea: Provide old trace power interfaces via .config option to not break
existing
On Friday 17 September 2010 18:24:12 Ingo Molnar wrote:
* Thomas Renninger tr...@suse.de wrote:
On Friday 17 September 2010 16:24:59 Ingo Molnar wrote:
[ You dont even have to document it, as good code is self-explanatory ;-) ]
I recently posted a patch exporting some things through
On Thu, Sep 9, 2010 at 9:54 AM, Ingo Molnar mi...@elte.hu wrote:
I think the ACPI tracepoints can be added on top of the proposed
patch. Is that ok?
Yeah - and the OMAP thing can be split up too if the OMAP folks prefer
it that way, but we still want to _see_ all the patches in this thread
* Jean Pihet jean.pi...@newoldbits.com wrote:
On Wed, Sep 8, 2010 at 8:53 AM, Ingo Molnar mi...@elte.hu wrote:
* Jean Pihet jean.pi...@newoldbits.com wrote:
Hi,
Here is a patch proposal for adding new trace events for power management.
Note: thread restarted after the initial
* Jean Pihet jean.pi...@newoldbits.com wrote:
Hi,
Here is a patch proposal for adding new trace events for power management.
Note: thread restarted after the initial discussions on LKML.
Also mind including the ACPI tracepoints we talked about? That way a lot
more people could test it,
+0200
Subject: [PATCH] [PATCH] tracing, perf: add more power related events
This patch adds new generic events for dynamic power management
tracing:
- clock events class: used for clock enable/disable and for
clock rate change,
- power_domain events class: used for power domains transitions
Here is some more information about the patch:
Initial discussion on LKML: cf.
http://marc.info/?l=linux-kernelm=128195697205096w=4,
PM debug and profiling wiki page with rationale, todo, patches, tools
screenshots ...:
http://omappedia.org/wiki/Power_Management_Debug_and_Profiling
On Tue, Sep
42 matches
Mail list logo
