Hi,
On Wed, Sep 29, 2010 at 9:49 AM, Thomas Renninger 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 rep
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
On Tuesday, September 28, 2010, Jean Pihet wrote:
> Hi,
>
> On Tue, Sep 28, 2010 at 11: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
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 pro
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_sst
Hi,
On Tue, Sep 28, 2010 at 11: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_
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 mea
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 of
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
[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
> pa
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 th
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 di
On Wednesday 22 September 2010 20:13:19 Arjan van de Ven wrote:
> 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 g
On Wed, 2010-09-22 at 20:23 +0200, Ingo Molnar wrote:
> * Steven Rostedt 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
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 yo
* Steven Rostedt 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 tracepoints change
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 TRACE_
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 bee
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, mo
On Wednesday 22 September 2010 17:33:01 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 interfa
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 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 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 here
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 majord...@vger.kern
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 A
On 9/22/2010 8:36 AM, Jean Pihet wrote:
On Wed, Sep 22, 2010 at 5:33 PM, 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 mo
On Wed, Sep 22, 2010 at 5:33 PM, 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 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 has
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 Friday 17 September 2010 18:24:12 Ingo Molnar wrote:
>
> * Thomas Renninger 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 /sys/kernel/d
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 perf/powertop
power-trace: Add x86 ACPI S- (machine sleep) state events.
Signed-off-by: Thomas Renninger
---
drivers/acpi/sleep.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
Index: linux-2.6.35-master/drivers/acpi/sleep.c
==
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
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 shou
* Thomas Renninger wrote:
> On Friday 17 September 2010 16:24:59 Ingo Molnar wrote:
> >
> > * Jean Pihet wrote:
> >
> > > > Apropos documentation..., are the power trace events documented
> > > > somewhere?
> > >
> > > No. We need something like Documentation/trace/events-kmem.txt. I
> > > ca
On Friday 17 September 2010 16:24:59 Ingo Molnar wrote:
>
> * Jean Pihet 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
On Friday 17 September 2010 16:05:51 Jean Pihet wrote:
> Hi Thomas,
>
> On Fri, Sep 17, 2010 at 3:08 PM, Thomas Renninger 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
* Jean Pihet 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 welcome!
In
Hi Thomas,
On Fri, Sep 17, 2010 at 3:08 PM, Thomas Renninger 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 code ne
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
On Thu, Sep 9, 2010 at 9:54 AM, Ingo Molnar 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
> togethe
* Jean Pihet wrote:
> On Wed, Sep 8, 2010 at 8:53 AM, Ingo Molnar wrote:
> >
> > * Jean Pihet 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
On Wed, Sep 8, 2010 at 8:53 AM, Ingo Molnar wrote:
>
> * Jean Pihet 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
* Jean Pihet 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, etc.
Ingo
--
To
Here is some more information about the patch:
Initial discussion on LKML: cf.
http://marc.info/?l=linux-kernel&m=128195697205096&w=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
45 matches
Mail list logo
