On 12/9/2013 10:08 PM, Alex Shi wrote:
And for monitor/mwait idle method, seems deep c-state cpu need to keep a
eye on memory bus. So seems the memory controller in cpu package is
impossible to get into sleep, right?
not the memory bus
the cache coherency logic ;-)
--
To unsubscribe from this
On 12/9/2013 10:08 PM, Alex Shi wrote:
And for monitor/mwait idle method, seems deep c-state cpu need to keep a
eye on memory bus. So seems the memory controller in cpu package is
impossible to get into sleep, right?
not the memory bus
the cache coherency logic ;-)
--
To unsubscribe from this
On 12/2/2013 11:03 AM, Steven Rostedt wrote:
Hi all!
The question has recently come up in Fedora about packaging the
libtraceevent.so library. Currently there's 4 users of it:
1) perf
2) trace-cmd
3) powertop
4) rasdaemon
But each have their own copy of the code.
Both perf and
On 12/2/2013 11:03 AM, Steven Rostedt wrote:
Hi all!
The question has recently come up in Fedora about packaging the
libtraceevent.so library. Currently there's 4 users of it:
1) perf
2) trace-cmd
3) powertop
4) rasdaemon
But each have their own copy of the code.
Both perf and
On 11/20/2013 9:55 AM, Thomas Gleixner wrote:
On Wed, 20 Nov 2013, Arjan van de Ven wrote:
On 11/20/2013 9:23 AM, Thomas Gleixner wrote:
On Wed, 20 Nov 2013, Arjan van de Ven wrote:
On 11/20/2013 8:04 AM, Peter Zijlstra wrote:
This does not fully preseve existing behaviour
On 11/20/2013 9:23 AM, Thomas Gleixner wrote:
On Wed, 20 Nov 2013, Arjan van de Ven wrote:
On 11/20/2013 8:04 AM, Peter Zijlstra wrote:
This does not fully preseve existing behaviour in that the generic
idle cycle function calls into the normal cpuidle governed idle
routines and should thus
On 11/20/2013 8:33 AM, Peter Zijlstra wrote:
On Wed, Nov 20, 2013 at 08:24:47AM -0800, Arjan van de Ven wrote:
On 11/20/2013 2:58 AM, Peter Zijlstra wrote:
So pretty silly actually; you cannot do a store (any store) in between
monitor and mwait.
you can
just not to the cacheline you
On 11/20/2013 2:58 AM, Peter Zijlstra wrote:
On Wed, Nov 20, 2013 at 11:28:03AM +0100, Peter Zijlstra wrote:
On Tue, Nov 19, 2013 at 01:06:30PM -0800, Jacob Pan wrote:
I applied this patch on top of upstream kernel (801a760) and found out
my machine completely failed to enter idle when nothing
On 11/20/2013 2:58 AM, Peter Zijlstra wrote:
On Wed, Nov 20, 2013 at 11:28:03AM +0100, Peter Zijlstra wrote:
On Tue, Nov 19, 2013 at 01:06:30PM -0800, Jacob Pan wrote:
I applied this patch on top of upstream kernel (801a760) and found out
my machine completely failed to enter idle when nothing
On 11/20/2013 8:33 AM, Peter Zijlstra wrote:
On Wed, Nov 20, 2013 at 08:24:47AM -0800, Arjan van de Ven wrote:
On 11/20/2013 2:58 AM, Peter Zijlstra wrote:
So pretty silly actually; you cannot do a store (any store) in between
monitor and mwait.
you can
just not to the cacheline you
On 11/20/2013 9:23 AM, Thomas Gleixner wrote:
On Wed, 20 Nov 2013, Arjan van de Ven wrote:
On 11/20/2013 8:04 AM, Peter Zijlstra wrote:
This does not fully preseve existing behaviour in that the generic
idle cycle function calls into the normal cpuidle governed idle
routines and should thus
On 11/20/2013 9:55 AM, Thomas Gleixner wrote:
On Wed, 20 Nov 2013, Arjan van de Ven wrote:
On 11/20/2013 9:23 AM, Thomas Gleixner wrote:
On Wed, 20 Nov 2013, Arjan van de Ven wrote:
On 11/20/2013 8:04 AM, Peter Zijlstra wrote:
This does not fully preseve existing behaviour
diff --git a/drivers/thermal/intel_powerclamp.c
b/drivers/thermal/intel_powerclamp.c
index 8f181b3f842b..e8275f2df9af 100644
--- a/drivers/thermal/intel_powerclamp.c
+++ b/drivers/thermal/intel_powerclamp.c
@@ -438,9 +438,7 @@ static int clamp_thread(void *arg)
*/
diff --git a/drivers/thermal/intel_powerclamp.c
b/drivers/thermal/intel_powerclamp.c
index 8f181b3f842b..e8275f2df9af 100644
--- a/drivers/thermal/intel_powerclamp.c
+++ b/drivers/thermal/intel_powerclamp.c
@@ -438,9 +438,7 @@ static int clamp_thread(void *arg)
*/
for picking the cpu to wake on there are also low level physical kind of things
we'd want to take into account on the intel side.
Are these static and could they be hidden behind some cost number in a
topology description? If they are dynamic, we would need arch or driver
hooks to give some
On 11/12/2013 3:14 PM, Catalin Marinas wrote:
On 12 Nov 2013, at 16:48, Arjan van de Ven wrote:
On 11/11/2013 10:18 AM, Catalin Marinas wrote:
The ordering is based on the actual C-state, so a simple way is to wake
up the CPU in the shallowest C-state. With asymmetric configurations
On 11/12/2013 3:14 PM, Catalin Marinas wrote:
On 12 Nov 2013, at 16:48, Arjan van de Ven ar...@linux.intel.com wrote:
On 11/11/2013 10:18 AM, Catalin Marinas wrote:
The ordering is based on the actual C-state, so a simple way is to wake
up the CPU in the shallowest C-state. With asymmetric
for picking the cpu to wake on there are also low level physical kind of things
we'd want to take into account on the intel side.
Are these static and could they be hidden behind some cost number in a
topology description? If they are dynamic, we would need arch or driver
hooks to give some
On 11/11/2013 10:18 AM, Catalin Marinas wrote:
The ordering is based on the actual C-state, so a simple way is to wake
up the CPU in the shallowest C-state. With asymmetric configurations
(big.LITTLE) we have different costs for the same C-state, so this would
come in handy.
btw I was
On 11/11/2013 10:18 AM, Catalin Marinas wrote:
The ordering is based on the actual C-state, so a simple way is to wake
up the CPU in the shallowest C-state. With asymmetric configurations
(big.LITTLE) we have different costs for the same C-state, so this would
come in handy.
btw I was
On 11/11/2013 10:31 AM, Catalin Marinas wrote:
I agree, we can't rely on the requested C-state but the_actual_ state
and this means querying the hardware driver. Can we abstract this via
some interface which provides the cost of waking up a CPU? This could
take into account the state of the
On 11/11/2013 10:18 AM, Catalin Marinas wrote:
Even for symmetric configuration, the cost of moving a task to a CPU
includes wake-up cost plus the run-time cost which depends on the
P-state after wake-up (that's much trickier since we can't easily
estimate the cost of a P-state and it may
I think the scheduler simply wants to say: we expect to go idle for X
ns, we want a guaranteed wakeup latency of Y ns -- go do your thing.
as long as Y normally is "large" or "infinity" that is ok ;-)
(a smaller Y will increase power consumption and decrease system performance)
I think
On 11/11/2013 8:38 AM, Peter Zijlstra wrote:
Like the package C states on x86 -- for those to be effective the
scheduler needs to pack tasks and keep entire packages idle for as long
as possible.
"package" C states on x86 are not really per package... but system wide.
the name is very
On 11/11/2013 8:38 AM, Peter Zijlstra wrote:
Like the package C states on x86 -- for those to be effective the
scheduler needs to pack tasks and keep entire packages idle for as long
as possible.
package C states on x86 are not really per package... but system wide.
the name is very confusing.
I think the scheduler simply wants to say: we expect to go idle for X
ns, we want a guaranteed wakeup latency of Y ns -- go do your thing.
as long as Y normally is large or infinity that is ok ;-)
(a smaller Y will increase power consumption and decrease system performance)
I think you
On 11/11/2013 10:18 AM, Catalin Marinas wrote:
Even for symmetric configuration, the cost of moving a task to a CPU
includes wake-up cost plus the run-time cost which depends on the
P-state after wake-up (that's much trickier since we can't easily
estimate the cost of a P-state and it may
On 11/11/2013 10:31 AM, Catalin Marinas wrote:
I agree, we can't rely on the requested C-state but the_actual_ state
and this means querying the hardware driver. Can we abstract this via
some interface which provides the cost of waking up a CPU? This could
take into account the state of the
fwiw this file lives on intel.com for a while now.. unfortunately it's
one of these websites with fancy downloading stuff for which I suspect
the URLs are not long term stable ;-(
but if you type "microcode" into the search box its the first entry...
On Thu, Nov 7, 2013 at 8:34 AM, Ingo Molnar
fwiw this file lives on intel.com for a while now.. unfortunately it's
one of these websites with fancy downloading stuff for which I suspect
the URLs are not long term stable ;-(
but if you type microcode into the search box its the first entry...
On Thu, Nov 7, 2013 at 8:34 AM, Ingo Molnar
We should be able to boil it down to a sequence on ARM as well. But it
means dropping cpufreq and looking at the clock framework.
Are you still using the pre- and post-change notifiers on Intel, or can
they be ignored safely?
we do not use change notifiers
(since the hardware changes
We should be able to boil it down to a sequence on ARM as well. But it
means dropping cpufreq and looking at the clock framework.
Are you still using the pre- and post-change notifiers on Intel, or can
they be ignored safely?
we do not use change notifiers
(since the hardware changes
cpufreq has pre- and post-change notifiers so the current TC2 clock driver
yeah those are EVIL ;-)
waits (yields) in its clk_set_rate() implementation until the change has
happened to ensure that the post-change notifier happens at the right
time. Since clk_set_rate() is allowed to sleep
On 10/17/2013 9:08 AM, Jan Beulich wrote:
On 17.10.13 at 18:04, Arjan van de Ven wrote:
... and the non-constant case be taken care of at run time.
That's precisely what the patch does.
fair enough.
I would like to see a comment above the code to describe this reasoning
and the objective
... and the non-constant case be taken care of at run time.
That's precisely what the patch does.
fair enough.
I would like to see a comment above the code to describe this reasoning
and the objective and what the desired behavior is... so that we don't
have to reverse engineer this again 2
On 10/17/2013 2:45 AM, Jan Beulich wrote:
Sure: Let's take __tun_chr_ioctl(): While a static function, it gets
called with two different values for ifreq_len, both of which are
provably (for a human) correct. I don't think, however, that the
compiler can be expected to do so on its own in all
On 10/17/2013 2:45 AM, Jan Beulich wrote:
Sure: Let's take __tun_chr_ioctl(): While a static function, it gets
called with two different values for ifreq_len, both of which are
provably (for a human) correct. I don't think, however, that the
compiler can be expected to do so on its own in all
... and the non-constant case be taken care of at run time.
That's precisely what the patch does.
fair enough.
I would like to see a comment above the code to describe this reasoning
and the objective and what the desired behavior is... so that we don't
have to reverse engineer this again 2
On 10/17/2013 9:08 AM, Jan Beulich wrote:
On 17.10.13 at 18:04, Arjan van de Ven ar...@linux.intel.com wrote:
... and the non-constant case be taken care of at run time.
That's precisely what the patch does.
fair enough.
I would like to see a comment above the code to describe
cpufreq has pre- and post-change notifiers so the current TC2 clock driver
yeah those are EVIL ;-)
waits (yields) in its clk_set_rate() implementation until the change has
happened to ensure that the post-change notifier happens at the right
time. Since clk_set_rate() is allowed to sleep
if you have found cases where this matters... maybe you found a new security
issue...
Iirc I could convince myself that in the cited cases the warnings
were there for no reason.
can you pick one on a source level ?
(and the gcc 4.6 had a few false positives which is why it got disabled
.
Adding the other direction is a good idea of course.
Signed-off-by: Jan Beulich
Cc: Arjan van de Ven
Cc: Guenter Roeck
+static inline unsigned long __must_check copy_from_user(void *to,
+ const void __user *from
.
Adding the other direction is a good idea of course.
Signed-off-by: Jan Beulich jbeul...@suse.com
Cc: Arjan van de Ven ar...@linux.intel.com
Cc: Guenter Roeck li...@roeck-us.net
+static inline unsigned long __must_check copy_from_user(void *to,
+ const void
if you have found cases where this matters... maybe you found a new security
issue...
Iirc I could convince myself that in the cited cases the warnings
were there for no reason.
can you pick one on a source level ?
(and the gcc 4.6 had a few false positives which is why it got disabled
On 10/14/2013 9:10 AM, Morten Rasmussen wrote:
On Mon, Oct 14, 2013 at 02:33:56PM +0100, Peter Zijlstra wrote:
On Fri, Oct 11, 2013 at 06:19:14PM +0100, Morten Rasmussen wrote:
Removing power hints for kworker threads enables easier use of
workqueues in the power driver late callback. That
On 10/14/2013 6:33 AM, Peter Zijlstra wrote:
On Fri, Oct 11, 2013 at 06:19:14PM +0100, Morten Rasmussen wrote:
Removing power hints for kworker threads enables easier use of
workqueues in the power driver late callback. That would otherwise
lead to an endless loop unless it is prevented in the
On 10/14/2013 6:33 AM, Peter Zijlstra wrote:
On Fri, Oct 11, 2013 at 06:19:14PM +0100, Morten Rasmussen wrote:
Removing power hints for kworker threads enables easier use of
workqueues in the power driver late callback. That would otherwise
lead to an endless loop unless it is prevented in the
On 10/14/2013 9:10 AM, Morten Rasmussen wrote:
On Mon, Oct 14, 2013 at 02:33:56PM +0100, Peter Zijlstra wrote:
On Fri, Oct 11, 2013 at 06:19:14PM +0100, Morten Rasmussen wrote:
Removing power hints for kworker threads enables easier use of
workqueues in the power driver late callback. That
somehow the domain no longer points to the right spot/etc
my attempts to get that fixed have failed so far ;-(
On Wed, Oct 9, 2013 at 9:42 AM, Daniel Walker wrote:
> Hi,
>
> Are you aware that http://www.latencytop.org/ is not functioning ? I was
> trying to get the update source code, but seem
somehow the domain no longer points to the right spot/etc
my attempts to get that fixed have failed so far ;-(
On Wed, Oct 9, 2013 at 9:42 AM, Daniel Walker dwal...@fifo99.com wrote:
Hi,
Are you aware that http://www.latencytop.org/ is not functioning ? I was
trying to get the update source
On 10/6/2013 1:15 PM, Gene Heskett wrote:
and if you wonder what linux does today without the framework; there are
mechanisms that kick in at the very end of the range, that are very
draconian like taking the 3.0Ghz processor down to effectively 100MHz,
or even a system reboot. The point of what
On 10/6/2013 1:15 PM, Gene Heskett wrote:
and if you wonder what linux does today without the framework; there are
mechanisms that kick in at the very end of the range, that are very
draconian like taking the 3.0Ghz processor down to effectively 100MHz,
or even a system reboot. The point of what
On 10/4/2013 4:17 PM, Gene Heskett wrote:
I hope this is a better explanation. :)
The idea of power capping is to cap total power not power down and also
need root level access to modify.
No. Restricting it to root control only is NOT an option. There has to be
some mechanism whereby the
On 10/4/2013 4:17 PM, Gene Heskett wrote:
I hope this is a better explanation. :)
The idea of power capping is to cap total power not power down and also
need root level access to modify.
No. Restricting it to root control only is NOT an option. There has to be
some mechanism whereby the
On 10/2/2013 5:45 AM, Frederic Weisbecker wrote:
On Tue, Oct 01, 2013 at 06:59:57PM +0200, Peter Zijlstra wrote:
On Tue, Oct 01, 2013 at 06:47:10PM +0200, Frederic Weisbecker wrote:
Yeah thinking more about it, the preempt disable was probably not
necessary. Now that's trading 2 atomics + 1
On 10/2/2013 5:45 AM, Frederic Weisbecker wrote:
On Tue, Oct 01, 2013 at 06:59:57PM +0200, Peter Zijlstra wrote:
On Tue, Oct 01, 2013 at 06:47:10PM +0200, Frederic Weisbecker wrote:
Yeah thinking more about it, the preempt disable was probably not
necessary. Now that's trading 2 atomics + 1
Arjan, are you referring to the fact that Intel/SNB systems can exploit
memory self-refresh only when the entire system goes idle? Is that why
this
patchset won't turn out to be that useful on those platforms?
no we can use other things (CKE and co) all the time.
Ah, ok..
just that we
On 9/26/2013 6:42 AM, Srivatsa S. Bhat wrote:
On 09/26/2013 08:29 AM, Andrew Morton wrote:
On Thu, 26 Sep 2013 03:50:16 +0200 Andi Kleen wrote:
On Wed, Sep 25, 2013 at 06:21:29PM -0700, Andrew Morton wrote:
On Wed, 25 Sep 2013 18:15:21 -0700 Arjan van de Ven
wrote:
On 9/25/2013 4:47 PM
On 9/26/2013 5:58 AM, Srivatsa S. Bhat wrote:
Let me explain the challenge I am facing. A prototype powerpc platform that
I work with has the capability to transition memory banks to content-preserving
low-power states at a per-socket granularity. What that means is that we can
get memory power
On 9/25/2013 6:21 PM, Andrew Morton wrote:
On Wed, 25 Sep 2013 18:15:21 -0700 Arjan van de Ven
wrote:
On 9/25/2013 4:47 PM, Andi Kleen wrote:
Also, the changelogs don't appear to discuss one obvious downside: the
latency incurred in bringing a bank out of one of the low-power states
On 9/25/2013 6:21 PM, Andrew Morton wrote:
On Wed, 25 Sep 2013 18:15:21 -0700 Arjan van de Ven ar...@linux.intel.com
wrote:
On 9/25/2013 4:47 PM, Andi Kleen wrote:
Also, the changelogs don't appear to discuss one obvious downside: the
latency incurred in bringing a bank out of one of the low
On 9/26/2013 5:58 AM, Srivatsa S. Bhat wrote:
Let me explain the challenge I am facing. A prototype powerpc platform that
I work with has the capability to transition memory banks to content-preserving
low-power states at a per-socket granularity. What that means is that we can
get memory power
On 9/26/2013 6:42 AM, Srivatsa S. Bhat wrote:
On 09/26/2013 08:29 AM, Andrew Morton wrote:
On Thu, 26 Sep 2013 03:50:16 +0200 Andi Kleen a...@firstfloor.org wrote:
On Wed, Sep 25, 2013 at 06:21:29PM -0700, Andrew Morton wrote:
On Wed, 25 Sep 2013 18:15:21 -0700 Arjan van de Ven ar
Arjan, are you referring to the fact that Intel/SNB systems can exploit
memory self-refresh only when the entire system goes idle? Is that why
this
patchset won't turn out to be that useful on those platforms?
no we can use other things (CKE and co) all the time.
Ah, ok..
just that we
On 9/25/2013 4:47 PM, Andi Kleen wrote:
Also, the changelogs don't appear to discuss one obvious downside: the
latency incurred in bringing a bank out of one of the low-power states
and back into full operation. Please do discuss and quantify that to
the best of your knowledge.
On Sandy
On 9/25/2013 4:47 PM, Andi Kleen wrote:
Also, the changelogs don't appear to discuss one obvious downside: the
latency incurred in bringing a bank out of one of the low-power states
and back into full operation. Please do discuss and quantify that to
the best of your knowledge.
On Sandy
On 9/25/2013 4:47 PM, Andi Kleen wrote:
Also, the changelogs don't appear to discuss one obvious downside: the
latency incurred in bringing a bank out of one of the low-power states
and back into full operation. Please do discuss and quantify that to
the best of your knowledge.
On Sandy
On 9/25/2013 4:47 PM, Andi Kleen wrote:
Also, the changelogs don't appear to discuss one obvious downside: the
latency incurred in bringing a bank out of one of the low-power states
and back into full operation. Please do discuss and quantify that to
the best of your knowledge.
On Sandy
On 9/10/2013 6:56 AM, Ingo Molnar wrote:
* Ingo Molnar wrote:
So what we do in kick_process() is:
preempt_disable();
cpu = task_cpu(p);
if ((cpu != smp_processor_id()) && task_curr(p))
smp_send_reschedule(cpu);
preempt_enable();
The
On 9/10/2013 6:56 AM, Ingo Molnar wrote:
* Ingo Molnar mi...@kernel.org wrote:
So what we do in kick_process() is:
preempt_disable();
cpu = task_cpu(p);
if ((cpu != smp_processor_id()) task_curr(p))
smp_send_reschedule(cpu);
On 8/20/2013 8:35 AM, Frederic Weisbecker wrote:
On Tue, Aug 20, 2013 at 08:33:50AM -0700, Arjan van de Ven wrote:
On 8/20/2013 8:29 AM, Frederic Weisbecker wrote:
Of course, if we can get away with completely removing all of that
(which I think Arjan suggested was a real possibility
On 8/20/2013 8:29 AM, Frederic Weisbecker wrote:
Of course, if we can get away with completely removing all of that
(which I think Arjan suggested was a real possibility) then that would
be ever so much better still :-)
Would be lovely. But I don't know much about cpufreq, I hope somebody
On 8/20/2013 1:44 AM, Peter Zijlstra wrote:
On Tue, Aug 20, 2013 at 03:59:36PM +0900, Fernando Luis Vázquez Cao wrote:
That said, if deemed acceptable, option A is the one I would
choose.
Right, so I think we can do A without much extra cost mostly because we
already have 2 atomics in the
On 8/20/2013 1:44 AM, Peter Zijlstra wrote:
On Tue, Aug 20, 2013 at 03:59:36PM +0900, Fernando Luis Vázquez Cao wrote:
That said, if deemed acceptable, option A is the one I would
choose.
Right, so I think we can do A without much extra cost mostly because we
already have 2 atomics in the
On 8/20/2013 8:29 AM, Frederic Weisbecker wrote:
Of course, if we can get away with completely removing all of that
(which I think Arjan suggested was a real possibility) then that would
be ever so much better still :-)
Would be lovely. But I don't know much about cpufreq, I hope somebody
On 8/20/2013 8:35 AM, Frederic Weisbecker wrote:
On Tue, Aug 20, 2013 at 08:33:50AM -0700, Arjan van de Ven wrote:
On 8/20/2013 8:29 AM, Frederic Weisbecker wrote:
Of course, if we can get away with completely removing all of that
(which I think Arjan suggested was a real possibility
On 8/19/2013 3:58 AM, Peter Zijlstra wrote:
On Fri, Aug 16, 2013 at 07:12:09PM +0200, Frederic Weisbecker wrote:
Or may be Peter could tell us as well. Peter, do you have a preference?
Still trying to wrap my head around it, but conceptually
get_cpu_iowait_time_us() doesn't make any kind of
On 8/19/2013 3:58 AM, Peter Zijlstra wrote:
I'm also not entirely clear on the 'desired' semantics here. Do we count
iowait time as idle or not?
cpufreq only looks at this because it does not want to count this as idle...
other than that it could not care less.
--
To unsubscribe from this
On 8/19/2013 3:58 AM, Peter Zijlstra wrote:
I'm also not entirely clear on the 'desired' semantics here. Do we count
iowait time as idle or not?
cpufreq only looks at this because it does not want to count this as idle...
other than that it could not care less.
--
To unsubscribe from this
On 8/19/2013 3:58 AM, Peter Zijlstra wrote:
On Fri, Aug 16, 2013 at 07:12:09PM +0200, Frederic Weisbecker wrote:
Or may be Peter could tell us as well. Peter, do you have a preference?
Still trying to wrap my head around it, but conceptually
get_cpu_iowait_time_us() doesn't make any kind of
On 8/2/2013 5:53 PM, Greg KH wrote:
I will post the one client driver, which is already using this
framework as this series.
Ideally you will have more than one client driver submitted, as a
"framework" for just one driver seems a bit odd, don't you think?
There are other groups and vendors
On 8/2/2013 5:53 PM, Greg KH wrote:
I will post the one client driver, which is already using this
framework as this series.
Ideally you will have more than one client driver submitted, as a
framework for just one driver seems a bit odd, don't you think?
There are other groups and vendors
On 7/29/2013 9:01 AM, Lorenzo Pieralisi wrote:
Coupled C states on this level are a PAIN in many ways, and tend to totally
suck for power
due to this and the general "too much is active" reasons.
I think the trend is moving towards core gating, which resembles a lot to what
x86 world does
On 7/29/2013 7:14 AM, Lorenzo Pieralisi wrote:
btw this is largely a misunderstanding;
tasks are not the issue; tasks use timers and those are perfectly predictable.
It's interrupts that are not and the heuristics are for that.
Now, if your hardware does the really-bad-for-power wake-all on
The menu governor tries to deduce the next wakeup but based on events
per cpu. That means if a task with a specific behavior is migrated
across cpus, the statistics will be wrong.
btw this is largely a misunderstanding;
tasks are not the issue; tasks use timers and those are perfectly
Beside that, on ARM the cpus could be coupled and the timer to detect
the prediction will wake up the entire cluster, making the power saving
less efficient and impacting the statistics of the other cpu.
an ARM specific governor would be quite appropriate in that case.
--
To unsubscribe from
Beside that, on ARM the cpus could be coupled and the timer to detect
the prediction will wake up the entire cluster, making the power saving
less efficient and impacting the statistics of the other cpu.
an ARM specific governor would be quite appropriate in that case.
--
To unsubscribe from
The menu governor tries to deduce the next wakeup but based on events
per cpu. That means if a task with a specific behavior is migrated
across cpus, the statistics will be wrong.
btw this is largely a misunderstanding;
tasks are not the issue; tasks use timers and those are perfectly
On 7/29/2013 7:14 AM, Lorenzo Pieralisi wrote:
btw this is largely a misunderstanding;
tasks are not the issue; tasks use timers and those are perfectly predictable.
It's interrupts that are not and the heuristics are for that.
Now, if your hardware does the really-bad-for-power wake-all on
On 7/29/2013 9:01 AM, Lorenzo Pieralisi wrote:
Coupled C states on this level are a PAIN in many ways, and tend to totally
suck for power
due to this and the general too much is active reasons.
I think the trend is moving towards core gating, which resembles a lot to what
x86 world does
On 7/26/2013 11:13 AM, Rik van Riel wrote:
Could you try running the tests with just the repeat mode
stuff from commit 69a37bea excluded, but leaving the common
infrastructure and commit e11538?
personally I think we should go the other way around.
revert the set entirely first, and now,
On 7/26/2013 11:13 AM, Rik van Riel wrote:
Could you try running the tests with just the repeat mode
stuff from commit 69a37bea excluded, but leaving the common
infrastructure and commit e11538?
personally I think we should go the other way around.
revert the set entirely first, and now,
I would expect performance to be disjoint for most tasks. If there was
an overlap, the big would probably be less power efficient (as in
energy/instruction) than the little so you would prefer to run on the
little anyway.
In what way would you use the overlap?
if the scheduler thinks a task
Given that the power topology is taken into account, a sort
left/right-like mechanism would only help performance insensitive tasks
on big.LITTLE. Performance sensitive tasks that each can use more than
a little cpu should move in the opposite direction. Well, directly to a
big cpu, even if
Given that the power topology is taken into account, a sort
left/right-like mechanism would only help performance insensitive tasks
on big.LITTLE. Performance sensitive tasks that each can use more than
a little cpu should move in the opposite direction. Well, directly to a
big cpu, even if
I would expect performance to be disjoint for most tasks. If there was
an overlap, the big would probably be less power efficient (as in
energy/instruction) than the little so you would prefer to run on the
little anyway.
In what way would you use the overlap?
if the scheduler thinks a task
On 7/16/2013 1:17 PM, Peter Zijlstra wrote:
On Tue, Jul 16, 2013 at 12:57:34PM -0700, Arjan van de Ven wrote:
then the question of how much remaining capacity; this is a hard one, and not
just
for Intel. Almost all mobile devices today are thermally constrained, ARM and
Intel
alike (at least
On 7/16/2013 1:17 PM, Peter Zijlstra wrote:
On Tue, Jul 16, 2013 at 12:57:34PM -0700, Arjan van de Ven wrote:
then the question of how much remaining capacity; this is a hard one, and not
just
for Intel. Almost all mobile devices today are thermally constrained, ARM and
Intel
alike (at least
On 7/16/2013 12:21 PM, Peter Zijlstra wrote:
Suppose a 2 cpu system, one cpu is running 3/4 throttle, the other is
running at half speed. Both cpus are equally utilized. A new task
comes on.
Where do we run it?
We need to know that there's head-room on the 1/2 speed cpu and should
crank its
On 7/16/2013 10:38 AM, Peter Zijlstra wrote:
On Mon, Jul 15, 2013 at 03:52:32PM -0700, Arjan van de Ven wrote:
yeah ondemand does this, but ondemand is actually a pretty bad governor.
not because of the sampling, but because of its algorithm.
Is it good for any class of hardware still out
301 - 400 of 3577 matches
Mail list logo
