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 t
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
>>
>> .. 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
On 12/21/2011 10:55 AM, Colin Cross wrote:
> On Wed, Dec 21, 2011 at 1:44 AM, Arjan van de Ven
> 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 y
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, s
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
>
-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-ti
: Arjan van de Ven
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...@vger.kernel.org
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 majord...@
On 8/19/2011 8:39 AM, Ming Lei wrote:
Hi,
On Fri, Aug 19, 2011 at 11:14 PM, Steven Rostedt wrote:
Do you know if these changes wont break powertop?
I have run powertop 1.13 on these changes, and found it works well
just like before,
no breaks found.
please use powertop 1.98 instead
1.13 does
On 4/7/2011 11:18 AM, Kevin Hilman wrote:
From: Nicole Chalhoub
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 pretty bad hack (
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. Wysocki wrote:
On Tuesday, October 26, 2010, Pierre Tardy wrote:
On Tue, Oct 26, 2010 at 12:58 PM, Peter Zijlstra wrote:
On Tue, 2010-10-26 at 11:56 -
On 10/26/2010 8:32 AM, Pierre Tardy wrote:
On Tue, Oct 26, 2010 at 2:10 AM, Ingo Molnar 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.
FYI, I have a
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
sy 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
--
To unsubscribe from this list: send the
On 10/25/2010 8:48 AM, Thomas Renninger wrote:
On Monday 25 October 2010 16:56:04 Ingo Molnar wrote:
* Arjan van de Ven 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 whereve
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 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:
/sys/devices/system/cpu/cpu
On 10/25/2010 4:03 AM, Thomas Renninger wrote:
On Monday 25 October 2010 12:04:28 Ingo Molnar wrote:
* 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
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/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/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 t
On 10/19/2010 6:50 AM, Ingo Molnar wrote:
* Arjan van de Ven wrote:
On 10/19/2010 4:52 AM, Ingo Molnar wrote:
* Peter Zijlstra wrote:
On Tue, 2010-10-19 at 13:45 +0200, Ingo Molnar wrote:
* Thomas Renninger wrote:
Most definitely. It's no accident that it took such a long
On 10/19/2010 4:52 AM, Ingo Molnar wrote:
* Peter Zijlstra wrote:
On Tue, 2010-10-19 at 13:45 +0200, Ingo Molnar wrote:
* Thomas Renninger wrote:
Most definitely. It's no accident that it took such a long time for this issue
to be raised in the first place. It's a rare occurance -
Do you
On 10/8/2010 11:28 PM, Ingo Molnar wrote:
* 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 develo
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
s
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 is
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
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 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 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
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
just as
> well add 4 seconds to all normal timers.
.. 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
de by 200 or 2000" makes the whole
problem go away.. in the "seconds" range for really 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,
b
On Sat, 5 Jun 2010 14:26:14 -0700
Arve Hjønnevåg wrote:
> On Sat, Jun 5, 2010 at 9:28 AM, Arjan van de Ven
> wrote:
> > On Sat, 05 Jun 2010 11:54:13 +0200
> > Peter Zijlstra wrote:
> >
> >> On Fri, 2010-06-04 at 17:10 -0700, Arve Hjønnevåg wrote:
> >&g
ven without doing things like putting untrusted
junk (read: Appstore apps) into a cgroup and do wakeup limiting and cpu
time limiting on a cgroup level
--
Arjan van de VenIntel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatt
quot;offline" is actually the same as "deepest C
state". At best.
As far as I can see, this is at least true for all Intel and AMD cpus.
And because there's then no power saving (but a performance cost), it's
actually a negative for battery life/total energy.
(lots of exp
37 matches
Mail list logo
