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 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 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 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 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 10/8/2010 1:38 AM, Ingo Molnar wrote:
The fundamental thing about tracing/instrumentation is that there are no
deep ABI needs: it's all about analyzing development kernels (and a few
select versions that get the enterprise treatment) but otherwise the
half-life of this kind of information
On 10/8/2010 6:41 AM, Mathieu Desnoyers wrote:
* Arjan van de Ven (ar...@linux.intel.com) wrote:
On 10/8/2010 1:38 AM, Ingo Molnar wrote:
The fundamental thing about tracing/instrumentation is that there are no
deep ABI needs: it's all about analyzing development kernels (and a few
select
On 10/8/2010 11:28 PM, Ingo Molnar wrote:
* Mathieu Desnoyersmathieu.desnoy...@efficios.com wrote:
* Arjan van de Ven (ar...@linux.intel.com) wrote:
On 10/8/2010 1:38 AM, Ingo Molnar wrote:
The fundamental thing about tracing/instrumentation is that there
are no deep ABI needs: it's all
On 10/19/2010 4:52 AM, Ingo Molnar wrote:
* Peter Zijlstrapet...@infradead.org wrote:
On Tue, 2010-10-19 at 13:45 +0200, Ingo Molnar wrote:
* Thomas Renningertr...@suse.de wrote:
Most definitely. It's no accident that it took such a long time for this issue
to be raised in the first
On 10/19/2010 6:50 AM, Ingo Molnar wrote:
* Arjan van de Venar...@linux.intel.com wrote:
On 10/19/2010 4:52 AM, Ingo Molnar wrote:
* Peter Zijlstrapet...@infradead.org wrote:
On Tue, 2010-10-19 at 13:45 +0200, Ingo Molnar wrote:
* Thomas Renningertr...@suse.de wrote:
Most
On 10/19/2010 4:36 AM, Thomas Renninger wrote:
static void poll_idle(void)
{
- trace_power_start(POWER_CSTATE, 0, smp_processor_id());
local_irq_enable();
while (!need_resched())
cpu_relax();
- trace_power_end(0);
}
why did you remove the idle
On 10/19/2010 4:36 AM, Thomas Renninger wrote:
New power trace events:
power:processor_idle
power:processor_frequency
power:machine_suspend
C-state/idle accounting events:
power:power_start
power:power_end
are replaced with:
power:processor_idle
I think you need two trace points for
On 10/25/2010 2:41 AM, Thomas Renninger wrote:
On Monday 25 October 2010 08:54:34 Arjan van de Ven wrote:
On 10/19/2010 4:36 AM, Thomas Renninger wrote:
static void poll_idle(void)
{
- trace_power_start(POWER_CSTATE, 0, smp_processor_id());
local_irq_enable();
while
On 10/25/2010 4:03 AM, Thomas Renninger wrote:
On Monday 25 October 2010 12:04:28 Ingo Molnar wrote:
* Thomas Renningertr...@suse.de wrote:
New power trace events:
power:processor_idle
power:processor_frequency
power:machine_suspend
C-state/idle accounting events:
power:power_start
On 10/25/2010 5:55 AM, Thomas Renninger wrote:
But the actual code does not actually deal with any 'state 0', does it?
It does. Not being idle is tracked by cpuidle driver as state 0
(arch independent):
/sys/devices/system/cpu/cpu0/cpuidle/state0/
halt/C1 on X86 is:
On 10/25/2010 7:36 AM, Thomas Renninger wrote:
I know that your new API tries to use 0 as exit, but 0 is already
taken (in all power terminology at least on x86 it is) for this.
cpuidle indeed misuses C0 as poll idle state.
That's really bad/misleading, but nothing that can be changed easily.
On 10/25/2010 8:48 AM, Thomas Renninger wrote:
On Monday 25 October 2010 16:56:04 Ingo Molnar wrote:
* Arjan van de Venar...@linux.intel.com wrote:
On 10/25/2010 7:36 AM, Thomas Renninger wrote:
ok so we have
C0 idle
Ideally this should not be called C0, but expressed
as (#define) POLL_IDLE
to add these events
in X86 as well if needed.
the type= field got removed from both, it was never
used and the type is differed by the event type itself.
perf timechart
userspace tool gets adjusted in a separate patch.
Acked-by: Arjan van de Ven ar...@linux.intel.com
--
To unsubscribe from
On 10/26/2010 12:10 AM, Ingo Molnar wrote:
+
+ TP_STRUCT__entry(
+ __field(u32,state )
+ __field(u32,cpu_id )
Trace entries can carry a cpu_id of the current processor already. Can this
cpu_id
ever be
On 10/26/2010 8:32 AM, Pierre Tardy wrote:
On Tue, Oct 26, 2010 at 2:10 AM, Ingo Molnarmi...@elte.hu wrote:
How will future PCI (or other device) power saving tracepoints be called?
Might be more consistent to use:
power:cpu_idle
power:machine_idle
power:device_idle
Agree with this.
On 10/26/2010 1:38 PM, Rafael J. Wysocki wrote:
On Tuesday, October 26, 2010, Pierre Tardy wrote:
On Tue, Oct 26, 2010 at 2:08 PM, Rafael J. Wysockir...@sisk.pl wrote:
On Tuesday, October 26, 2010, Pierre Tardy wrote:
On Tue, Oct 26, 2010 at 12:58 PM, Peter Zijlstrapet...@infradead.org
)
--
Arjan van de VenIntel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info
On Sat, 5 Jun 2010 14:26:14 -0700
Arve Hjønnevåg a...@android.com wrote:
On Sat, Jun 5, 2010 at 9:28 AM, Arjan van de Ven
ar...@infradead.org wrote:
On Sat, 05 Jun 2010 11:54:13 +0200
Peter Zijlstra pet...@infradead.org wrote:
On Fri, 2010-06-04 at 17:10 -0700, Arve Hjønnevåg wrote
low power devices.
Not in hours range.
On laptops (which have much more poor powermanagement) this point is
around 40 milliseconds or so.. but on phone silicon that I've seen,
both Intel and others, this is in the 1 to 5 seconds range.
--
Arjan van de VenIntel Open Source Technology
.
.. with the difference that with range timers, you naturally align with
other activity, so if there's system level activity, the AVERAGE service
the app gets is better by a LOT than just adding 4 seconds always.
but you knew that just doesn't help your case.
--
Arjan van de VenIntel Open Source
-by: Arjan van de Ven
ar...@linux.intel.com
it's a good simplification of the code, and unlike frequencies, idle
states are really shared between all cpus for
very practical reasons.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/28/2011 3:50 AM, Deepthi Dharwar wrote:
The cpuidle_device-prepare() mechanism causes updates to the
cpuidle_state[].flags, setting and clearing CPUIDLE_FLAG_IGNORE
to tell the governor not to chose a state on a per-cpu basis at
run-time.
It mentions that Version 1.13 is the latest version of PowerTOP, also
no any information about 1.98. so where can I get 1.98? thanks,
http://www.kernel.org/pub/linux/status/powertop
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
On 4/7/2011 11:18 AM, Kevin Hilman wrote:
From: Nicole Chalhoubn-chalh...@ti.com
While there is CPU load, continue the periodic tick in order to give
CPUidle another opportunity to pick a deeper C-state instead of
spending potentially long i
so I don't really like this patch. It's actually a
On 3/13/2012 4:52 PM, Kevin Hilman wrote:
Checking the ready_count seemed like an easy way to do this, but did you
have any other mechanisms in mind for CPUs to communicate that they've
exited/aborted?
this indeed is the tricky part (which I warned about earlier);
I've spent quite a lot of
On 12/21/2011 1:09 AM, Colin Cross wrote:
On some ARM SMP SoCs (OMAP4460, Tegra 2, and probably more), the
cpus cannot be independently powered down, either due to
sequencing restrictions (on Tegra 2, cpu 0 must be the last to
power down), or due to HW bugs (on OMAP4460, a cpu powering up
On 12/21/2011 10:40 AM, Colin Cross wrote:
this smells fundamentally racey to me; you can get an interrupt one
cycle after you think you're done, but before the last guy enters WFI...
how do you solve that issue ?
All the cpus have interrupts off when they increment the counter, so
they
On 12/21/2011 10:55 AM, Colin Cross wrote:
On Wed, Dec 21, 2011 at 1:44 AM, Arjan van de Ven ar...@linux.intel.com
wrote:
On 12/21/2011 10:40 AM, Colin Cross wrote:
this smells fundamentally racey to me; you can get an interrupt one
cycle after you think you're done, but before the last guy
.. or it enters WFI, and a physical device sends it an interrupt,
at which point it exits.
None of the cpus will return to the idle loop until all cpus have
decremented the ready counter back to 0, so they can't wrap around
again.
yikes, so you IPI all the cpus on the first exit.
that
On 12/22/2011 9:35 AM, Shilimkar, Santosh wrote:
Indeed. The SOCs, Arch's which does support low power
state independently and doesn't need any co-ordination between CPU's
will continue to work same way as before with this series.
btw I think you misunderstand; I don't object to a need for
35 matches
Mail list logo
