On Sun, Jun 06, 2010 at 05:47:10PM +0200, Vitaly Wool wrote:
2010/6/6 Matthew Garrett mj...@srcf.ucam.org:
The difference between idle-based suspend and opportunistic suspend is
that the former will continue to wake up for timers and will never be
entered if something is using CPU, whereas
On Sun, 2010-06-06 at 17:46 +0200, Thomas Gleixner wrote:
On Sun, 6 Jun 2010, James Bottomley wrote:
3. We've lost sight of one of the original goals, which was to
bring the android tree close enough to the kernel so that the
android downstream driver and board
2010/6/6 Matthew Garrett mj...@srcf.ucam.org:
Suspend blocks prevent system suspend, not any per-device suspend.
Can you suspend a device which is holding a wake lock?
~Vitaly
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
On Sun, Jun 06, 2010 at 07:21:49PM +0200, Vitaly Wool wrote:
2010/6/6 Matthew Garrett mj...@srcf.ucam.org:
Suspend blocks prevent system suspend, not any per-device suspend.
Can you suspend a device which is holding a wake lock?
Yes. Suspend blocks are orthogonal to runtime PM.
--
James,
On Sun, 6 Jun 2010, James Bottomley wrote:
On Sun, 2010-06-06 at 17:46 +0200, Thomas Gleixner wrote:
On Sun, 6 Jun 2010, James Bottomley wrote:
3. We've lost sight of one of the original goals, which was to
bring the android tree close enough to the kernel so that
On Sun, Jun 6, 2010 at 11:04 AM, Thomas Gleixner t...@linutronix.de wrote:
Right, so the sooner we make it easier for the drivers to use the kernel
as their main repository, the better.
Yep, the fastest way is to provide two stub inlines in pm.h and let
the driver flood come in.
As
On Sunday 06 June 2010, Matthew Garrett wrote:
On Sun, Jun 06, 2010 at 07:21:49PM +0200, Vitaly Wool wrote:
2010/6/6 Matthew Garrett mj...@srcf.ucam.org:
Suspend blocks prevent system suspend, not any per-device suspend.
Can you suspend a device which is holding a wake lock?
Yes.
On Sun, Jun 06, 2010 at 12:08:34PM -0500, James Bottomley wrote:
Well, we sort of tried this when Greg pulled some of them into the
staging tree. The problem is that without the annotations, the drivers
are still different, and patches won't apply, so, unsurprisingly, they
didn't get improved
On Sun, Jun 6, 2010 at 12:05 PM, Christoph Hellwig h...@infradead.org wrote:
On Sun, Jun 06, 2010 at 12:08:34PM -0500, James Bottomley wrote:
Well, we sort of tried this when Greg pulled some of them into the
staging tree. The problem is that without the annotations, the drivers
are still
On Sun, Jun 06, 2010 at 12:15:10PM -0700, Brian Swetland wrote:
I was shocked when Greg pulled the binder driver and some of the other
generic android drivers into staging, because it was always my
assumption that nobody upstream would want them. We did get some
bugfixes for the binder driver
On Sun, 6 Jun 2010, Brian Swetland wrote:
On Sun, Jun 6, 2010 at 11:04 AM, Thomas Gleixner t...@linutronix.de wrote:
Right, so the sooner we make it easier for the drivers to use the kernel
as their main repository, the better.
Yep, the fastest way is to provide two stub inlines in
On Sun, Jun 6, 2010 at 12:24 PM, Christoph Hellwig h...@infradead.org wrote:
Yes. That's what makes me wonder about some parts of the discussion
here. Getting the drivers for one or more of the android plattforms
in is not a problem. I'd say it could have easily been done with the
manweeks
Brian,
On Sun, 6 Jun 2010, Brian Swetland wrote:
On Sun, Jun 6, 2010 at 12:24 PM, Christoph Hellwig h...@infradead.org wrote:
Yes. That's what makes me wonder about some parts of the discussion
here. Getting the drivers for one or more of the android plattforms
in is not a problem.
On Sun, 6 Jun 2010, Matthew Garrett wrote:
The difference between idle-based suspend and opportunistic suspend is
that the former will continue to wake up for timers and will never be
entered if something is using CPU, whereas the latter will be entered
whenever no suspend blocks are held.
On Fri, 2010-06-04 at 17:10 -0700, Arve Hjønnevåg wrote:
Trusted processes are assumed to be sane and idle when there is nothing
for them to do, allowing the machine to go into deep idle states.
Neither the kernel nor our trusted user-space code currently meets
this criteria.
Then both
B1;2005;0cOn Fri, 4 Jun 2010, Arve Hjønnevåg wrote:
2010/6/4 Thomas Gleixner t...@linutronix.de:
Arve,
On Fri, 4 Jun 2010, Arve Hjønnevåg wrote:
On Fri, Jun 4, 2010 at 5:05 PM, Thomas Gleixner t...@linutronix.de wrote:
On Sat, 5 Jun 2010, Rafael J. Wysocki wrote:
I kind of agree
On Saturday 05 June 2010, Arve Hjønnevåg wrote:
2010/6/4 Matt Helsley matth...@us.ibm.com:
On Fri, Jun 04, 2010 at 05:39:17PM -0700, Arve Hjønnevåg wrote:
On Fri, Jun 4, 2010 at 5:05 PM, Thomas Gleixner t...@linutronix.de wrote:
On Sat, 5 Jun 2010, Rafael J. Wysocki wrote:
snip
On Thu, 3 Jun 2010 19:16:55 -0700 (PDT)
Linus Torvalds torva...@linux-foundation.org wrote:
The thing is, unless there is some _really_ deep other reason to do
something like this, I still think it's total overdesign to push any
knowledge/choices like this into the scheduler. I'd rather keep
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:
Trusted processes are assumed to be sane and idle when there is
nothing for
2010/6/5 Thomas Gleixner t...@linutronix.de:
B1;2005;0cOn Fri, 4 Jun 2010, Arve Hjønnevåg wrote:
2010/6/4 Thomas Gleixner t...@linutronix.de:
Arve,
On Fri, 4 Jun 2010, Arve Hjønnevåg wrote:
On Fri, Jun 4, 2010 at 5:05 PM, Thomas Gleixner t...@linutronix.de
wrote:
On Sat, 5 Jun
2010/6/5 Rafael J. Wysocki r...@sisk.pl:
On Saturday 05 June 2010, Arve Hjønnevåg wrote:
2010/6/4 Matt Helsley matth...@us.ibm.com:
On Fri, Jun 04, 2010 at 05:39:17PM -0700, Arve Hjønnevåg wrote:
On Fri, Jun 4, 2010 at 5:05 PM, Thomas Gleixner t...@linutronix.de
wrote:
On Sat, 5 Jun
On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
2010/6/5 Thomas Gleixner t...@linutronix.de:
B1;2005;0cOn Fri, 4 Jun 2010, Arve Hjønnevåg wrote:
Why is it a BUG in the trusted app, when I initiate a download and put
the phone down ?
It is not, but we have had bugs where a trusted app
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:
On Sat, Jun 5, 2010 at 3:23 PM, Arjan van de Ven ar...@infradead.org wrote:
We clearly have different standards for what we consider good. We
measure time suspended in minutes or hours, not seconds, and waking up
every second or two causes a noticeable decrease in battery life on
the hardware
2010/6/5 Arjan van de Ven ar...@infradead.org:
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,
On Saturday 05 June 2010, Arve Hjønnevåg wrote:
2010/6/5 Thomas Gleixner t...@linutronix.de:
B1;2005;0cOn Fri, 4 Jun 2010, Arve Hjønnevåg wrote:
2010/6/4 Thomas Gleixner t...@linutronix.de:
Arve,
On Fri, 4 Jun 2010, Arve Hjønnevåg wrote:
On Fri, Jun 4, 2010 at 5:05 PM, Thomas
On Sat, 5 Jun 2010 15:26:36 -0700
Brian Swetland swetl...@google.com wrote:
I'm continually surprised by answers like this. We run on hardware
that power gates very aggressively and draws in the neighborhood of
1-2mA at the battery when in the lowest state (3-5mA while the radio
is
On Sunday 06 June 2010, Brian Swetland wrote:
On Sat, Jun 5, 2010 at 3:23 PM, Arjan van de Ven ar...@infradead.org wrote:
We clearly have different standards for what we consider good. We
measure time suspended in minutes or hours, not seconds, and waking up
every second or two causes a
On Sunday 06 June 2010, Arve Hjønnevåg wrote:
2010/6/5 Rafael J. Wysocki r...@sisk.pl:
On Saturday 05 June 2010, Arve Hjønnevåg wrote:
2010/6/4 Matt Helsley matth...@us.ibm.com:
On Fri, Jun 04, 2010 at 05:39:17PM -0700, Arve Hjønnevåg wrote:
On Fri, Jun 4, 2010 at 5:05 PM, Thomas
2010/6/5 Thomas Gleixner t...@linutronix.de:
On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
2010/6/5 Thomas Gleixner t...@linutronix.de:
B1;2005;0cOn Fri, 4 Jun 2010, Arve Hjønnevåg wrote:
Why is it a BUG in the trusted app, when I initiate a download and put
the phone down ?
It is
On Sat, 5 Jun 2010 15:39:44 -0700
Arve Hjønnevåg a...@android.com wrote:
For example if the Adobe Flash player puts a timer every 10
milliseconds (yes it does that), and you give it a 3.99 seconds
range, it will fire its timers every 4 seconds unless other
activity happens
On Sunday 06 June 2010, Arve Hjønnevåg wrote:
2010/6/5 Thomas Gleixner t...@linutronix.de:
On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
2010/6/5 Thomas Gleixner t...@linutronix.de:
B1;2005;0cOn Fri, 4 Jun 2010, Arve Hjønnevåg wrote:
...
So taking your example:
Event happens and gets
On Sat, 5 Jun 2010, Arjan van de Ven wrote:
On Sat, 5 Jun 2010 15:26:36 -0700
Brian Swetland swetl...@google.com wrote:
I'm continually surprised by answers like this. We run on hardware
that power gates very aggressively and draws in the neighborhood of
1-2mA at the battery when in
2010/6/5 Rafael J. Wysocki r...@sisk.pl:
On Saturday 05 June 2010, Arve Hjønnevåg wrote:
2010/6/5 Thomas Gleixner t...@linutronix.de:
B1;2005;0cOn Fri, 4 Jun 2010, Arve Hjønnevåg wrote:
2010/6/4 Thomas Gleixner t...@linutronix.de:
Arve,
On Fri, 4 Jun 2010, Arve Hjønnevåg wrote:
2010/6/5 Arjan van de Ven ar...@infradead.org:
On Sat, 5 Jun 2010 15:39:44 -0700
Arve Hjønnevåg a...@android.com wrote:
For example if the Adobe Flash player puts a timer every 10
milliseconds (yes it does that), and you give it a 3.99 seconds
range, it will fire its timers every 4
On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
2010/6/5 Thomas Gleixner t...@linutronix.de:
On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
That download might take a minute or two, but that's not an
justification for the crapplication to run unconfined and prevent
lower power states.
On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
2010/6/5 Thomas Gleixner t...@linutronix.de:
Well, that's simply an application bug which sucks battery with or
without suspend blockers. So it's unrelated to the freezing of
untrusted apps while a trusted app still works in the background
On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
2010/6/5 Thomas Gleixner t...@linutronix.de:
On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
2010/6/5 Thomas Gleixner t...@linutronix.de:
B1;2005;0cOn Fri, 4 Jun 2010, Arve Hjønnevåg wrote:
Cross app calls do not go through a central process.
It's
On Sat, Jun 5, 2010 at 3:48 PM, Arjan van de Ven ar...@infradead.org wrote:
On Sat, 5 Jun 2010 15:26:36 -0700
Brian Swetland swetl...@google.com wrote:
I'm continually surprised by answers like this. We run on hardware
that power gates very aggressively and draws in the neighborhood of
2010/6/5 Rafael J. Wysocki r...@sisk.pl:
On Sunday 06 June 2010, Arve Hjønnevåg wrote:
2010/6/5 Rafael J. Wysocki r...@sisk.pl:
On Saturday 05 June 2010, Arve Hjønnevåg wrote:
2010/6/4 Matt Helsley matth...@us.ibm.com:
On Fri, Jun 04, 2010 at 05:39:17PM -0700, Arve Hjønnevåg wrote:
On
2010/6/5 Thomas Gleixner t...@linutronix.de:
On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
2010/6/5 Thomas Gleixner t...@linutronix.de:
On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
That download might take a minute or two, but that's not an
justification for the crapplication to run
2010/6/5 Thomas Gleixner t...@linutronix.de:
On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
2010/6/5 Thomas Gleixner t...@linutronix.de:
Well, that's simply an application bug which sucks battery with or
without suspend blockers. So it's unrelated to the freezing of
untrusted apps while a
2010/6/5 Thomas Gleixner t...@linutronix.de:
On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
2010/6/5 Thomas Gleixner t...@linutronix.de:
On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
2010/6/5 Thomas Gleixner t...@linutronix.de:
B1;2005;0cOn Fri, 4 Jun 2010, Arve Hjønnevåg wrote:
Cross app calls
On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
Yes, we can keep all our user space suspend blockers and thaw the
frozen cgroup when any suspend blocker is held, but this would
eliminate any power advantage that freezing a cgroup has over using
suspend to freeze all processes. Without annotating
* Linus Torvalds torva...@linux-foundation.org wrote:
[...]
And those two things go together. The /sys/power/state thing is a global
suspend - which I don't think is appropriate for a opportunistic thing in
the first place, especially for multi-core.
A well-designed opportunistic
* Arve Hj?nnev?g a...@android.com wrote:
On Thu, Jun 3, 2010 at 4:23 PM, Ingo Molnar mi...@elte.hu wrote:
...
?- Controlled auto-suspend: drivers (such as input) could on wakeup
? automatically set the 'minimum wakeup latency' value of wakee tasks to a
? lower value. This automatically
On Fri, Jun 4, 2010 at 12:13 AM, Ingo Molnar mi...@elte.hu wrote:
* Arve Hj?nnev?g a...@android.com wrote:
On Thu, Jun 3, 2010 at 4:23 PM, Ingo Molnar mi...@elte.hu wrote:
...
?- Controlled auto-suspend: drivers (such as input) could on wakeup
? automatically set the 'minimum wakeup
* Brian Swetland swetl...@google.com wrote:
On Thu, Jun 3, 2010 at 12:30 PM, Ingo Molnar mi...@elte.hu wrote:
Sadly the response from the Android team has been 100% uncompromising:
either
suspend blockers or nothing.
Well, we're willing to accept something that gives us the same
* Linus Torvalds torva...@linux-foundation.org wrote:
On Fri, 4 Jun 2010, Ingo Molnar wrote:
What you say is absolutely true, hence this would be driven via
sched_tick() + TIF notifiers - i.e. only ever treat user-mode tasks as
'idle-able'. This can be done with no overhead to the
* Arjan van de Ven ar...@infradead.org wrote:
On Thu, 3 Jun 2010 19:26:50 -0700 (PDT)
Linus Torvalds torva...@linux-foundation.org wrote:
If the system is idle (or almost idle) for long times, I would heartily
recommend actively shutting down unused cores. Some CPU's are hopefully
On Fri, Jun 4, 2010 at 12:57 AM, Ingo Molnar mi...@elte.hu wrote:
* Brian Swetland swetl...@google.com wrote:
We started here because it's possibly the only api level change we have --
almost everything else is driver or subarch type work or controversial but
entirely self-contained (like the
* Arve Hj?nnev?g a...@android.com wrote:
[...]
Why do you need to track input wakeups? It's rather fragile and rather
unnecessary [...]
Because we have keys that should always turn the screen on, but the problem
is not specific to input events. If we enabled a wakeup event it
* Brian Swetland swetl...@google.com wrote:
On Fri, Jun 4, 2010 at 12:57 AM, Ingo Molnar mi...@elte.hu wrote:
* Brian Swetland swetl...@google.com wrote:
We started here because it's possibly the only api level change we have
-- almost everything else is driver or subarch type work or
On Fri, Jun 4, 2010 at 1:34 AM, Ingo Molnar mi...@elte.hu wrote:
* Arve Hj?nnev?g a...@android.com wrote:
[...]
Why do you need to track input wakeups? It's rather fragile and rather
unnecessary [...]
Because we have keys that should always turn the screen on, but the problem
is not
On Fri, Jun 4, 2010 at 11:55 AM, Ingo Molnar mi...@elte.hu wrote:
In any case, this is not to suggest that the suspend-blocker bits are
'impossible' to merge. I just say that if you start with your most difficult
feature you should not be surprised to be on the receiving end of a 1000+
mails
On Fri, Jun 4, 2010 at 1:55 AM, Ingo Molnar mi...@elte.hu wrote:
* Brian Swetland swetl...@google.com wrote:
After basically two years of growing your fork (and some attempts to get
your drivers into drivers/staging/ - from where they have meanwhile
dropped out again) you re-started with
On Fri, 2010-06-04 at 01:23 +0200, Ingo Molnar wrote:
Btw., i'd like to summarize the scheduler based suspend scheme proposed by
Thomas Gleixner, Peter Zijlstra and myself. I found no good summary of it in
the big thread, and there are also new elements of the proposal:
Just to clarify, my
On Fri, 2010-06-04 at 11:43 +0200, Peter Zijlstra wrote:
I still believe containment is a cgroup problem. The freeze/snapshot/resume
container folks seem to face many of the same problems. Including the
pending timer one I suspect. Lets solve it there.
While talking to Thomas about this, we'd
* Brian Swetland swetl...@google.com wrote:
On Fri, Jun 4, 2010 at 1:55 AM, Ingo Molnar mi...@elte.hu wrote:
* Brian Swetland swetl...@google.com wrote:
After basically two years of growing your fork (and some attempts to get
your drivers into drivers/staging/ - from where they have
* Peter Zijlstra pet...@infradead.org wrote:
On Fri, 2010-06-04 at 11:43 +0200, Peter Zijlstra wrote:
I still believe containment is a cgroup problem. The freeze/snapshot/resume
container folks seem to face many of the same problems. Including the
pending timer one I suspect. Lets solve
On Fri, 2010-06-04 at 12:03 +0200, Ingo Molnar wrote:
The only 'interesting' issue I can see here is that if you create 1000
CLOCK_MONOTONIC namepaces, we'd need to have a tree of trees in order to
efficiently find the leftmost timer.
Realistically Android userspace would create just a
On Fri, Jun 4, 2010 at 2:59 AM, Ingo Molnar mi...@elte.hu wrote:
You can certainly put in a suspend_blockers.h thing into some Android
directory, and populate it with empty wrappers - as long as you only use it
within Android drivers and not core kernel code or other subsystems you dont
On Fri, Jun 4, 2010 at 3:08 AM, Peter Zijlstra pet...@infradead.org wrote:
On Fri, 2010-06-04 at 12:03 +0200, Ingo Molnar wrote:
The only 'interesting' issue I can see here is that if you create 1000
CLOCK_MONOTONIC namepaces, we'd need to have a tree of trees in order to
efficiently find
On Fri, 4 Jun 2010, Peter Zijlstra wrote:
On Fri, 2010-06-04 at 11:43 +0200, Peter Zijlstra wrote:
I still believe containment is a cgroup problem. The freeze/snapshot/resume
container folks seem to face many of the same problems. Including the
pending timer one I suspect. Lets solve it
On Fri, 2010-06-04 at 12:11 +0200, Thomas Gleixner wrote:
On Fri, 4 Jun 2010, Peter Zijlstra wrote:
On Fri, 2010-06-04 at 11:43 +0200, Peter Zijlstra wrote:
I still believe containment is a cgroup problem. The
freeze/snapshot/resume
container folks seem to face many of the same
Linus Torvalds torva...@linux-foundation.org writes:
On Thu, 3 Jun 2010, Arjan van de Ven wrote:
And because there's then no power saving (but a performance cost), it's
actually a negative for battery life/total energy.
Including the UP optimizations we do (ie lock prefix removal)? It's
On Fri, 2010-06-04 at 01:56 -0700, Arve Hjønnevåg wrote:
On Fri, Jun 4, 2010 at 1:34 AM, Ingo Molnar mi...@elte.hu wrote:
* Arve Hj?nnev?g a...@android.com wrote:
[...]
Why do you need to track input wakeups? It's rather fragile and rather
unnecessary [...]
Because we have
On Fri, 2010-06-04 at 11:59 +0200, Ingo Molnar wrote:
* Brian Swetland swetl...@google.com wrote:
On Fri, Jun 4, 2010 at 1:55 AM, Ingo Molnar mi...@elte.hu wrote:
* Brian Swetland swetl...@google.com wrote:
[...]
In any case, this is not to suggest that the suspend-blocker bits are
On Fri, 4 Jun 2010, Ingo Molnar wrote:
Note that this does not necessarily have to be implemented as 'execute
suspend
from the idle task' code: scheduling from the idle task, while can certainly
be made to work, is a somewhat recursive concept that we might want to avoid
for robustness
On Fri, 04 Jun 2010 09:24:06 -0500
James Bottomley james.bottom...@suse.de wrote:
On Fri, 2010-06-04 at 11:59 +0200, Ingo Molnar wrote:
Anyway, i'm not pessimistic at all: _some_ sort of scheme appears to be
crystalising out today. Everyone seems to agree now that the main usecases
are
On Friday 04 June 2010, Peter Zijlstra wrote:
On Fri, 2010-06-04 at 01:23 +0200, Ingo Molnar wrote:
Btw., i'd like to summarize the scheduler based suspend scheme proposed by
Thomas Gleixner, Peter Zijlstra and myself. I found no good summary of it in
the big thread, and there are also new
On Sat, 5 Jun 2010, Rafael J. Wysocki wrote:
I kind of agree here, so I'd like to focus a bit on that.
Here's my idea in the very general terms:
(1) Use the cgroup freezer to suspend the untrusted apps (ie. the ones
that don't use suspend blockers aka wakelocks in the Android world) at
2010/6/4 Peter Zijlstra pet...@infradead.org:
On Fri, 2010-06-04 at 01:56 -0700, Arve Hjønnevåg wrote:
On Fri, Jun 4, 2010 at 1:34 AM, Ingo Molnar mi...@elte.hu wrote:
* Arve Hj?nnev?g a...@android.com wrote:
[...]
Why do you need to track input wakeups? It's rather fragile and
On Fri, Jun 4, 2010 at 5:05 PM, Thomas Gleixner t...@linutronix.de wrote:
On Sat, 5 Jun 2010, Rafael J. Wysocki wrote:
I kind of agree here, so I'd like to focus a bit on that.
Here's my idea in the very general terms:
(1) Use the cgroup freezer to suspend the untrusted apps (ie. the ones
On Fri, Jun 04, 2010 at 05:39:17PM -0700, Arve Hjønnevåg wrote:
On Fri, Jun 4, 2010 at 5:05 PM, Thomas Gleixner t...@linutronix.de wrote:
On Sat, 5 Jun 2010, Rafael J. Wysocki wrote:
snip
With the cgroup freezer you can suspend them right away and
just keep the trusted
Arve,
On Fri, 4 Jun 2010, Arve Hjønnevåg wrote:
On Fri, Jun 4, 2010 at 5:05 PM, Thomas Gleixner t...@linutronix.de wrote:
On Sat, 5 Jun 2010, Rafael J. Wysocki wrote:
I kind of agree here, so I'd like to focus a bit on that.
Here's my idea in the very general terms:
(1) Use the
2010/6/4 Thomas Gleixner t...@linutronix.de:
Arve,
On Fri, 4 Jun 2010, Arve Hjønnevåg wrote:
On Fri, Jun 4, 2010 at 5:05 PM, Thomas Gleixner t...@linutronix.de wrote:
On Sat, 5 Jun 2010, Rafael J. Wysocki wrote:
I kind of agree here, so I'd like to focus a bit on that.
Here's my idea
2010/6/4 Matt Helsley matth...@us.ibm.com:
On Fri, Jun 04, 2010 at 05:39:17PM -0700, Arve Hjønnevåg wrote:
On Fri, Jun 4, 2010 at 5:05 PM, Thomas Gleixner t...@linutronix.de wrote:
On Sat, 5 Jun 2010, Rafael J. Wysocki wrote:
snip
With the cgroup freezer you can suspend them right
* ty...@mit.edu ty...@mit.edu wrote:
[...] Not only has the source code been made available, but hundreds of
engineering hours have been made trying to accomodate the demands of LKML
--- and LKML has said no to suspend blockers/wakelocks.
I dont think you are being fair here, at all.
On Thu, Jun 3, 2010 at 12:30 PM, Ingo Molnar mi...@elte.hu wrote:
Sadly the response from the Android team has been 100% uncompromising: either
suspend blockers or nothing.
Well, we're willing to accept something that gives us the same
functionality (thus rewriting the api several times to
* Ingo Molnar mi...@elte.hu wrote:
* ty...@mit.edu ty...@mit.edu wrote:
[...] Not only has the source code been made available, but hundreds of
engineering hours have been made trying to accomodate the demands of LKML
--- and LKML has said no to suspend blockers/wakelocks.
I dont
On Fri, 4 Jun 2010, Ingo Molnar wrote:
This allows a task to 'exclude' other tasks that dont have low-latency
requirements. Crappy apps would have a large latency value, so they'd
be idled out when a privileged task sets the exclusion level low enough.
Quite frankly, this sounds
* Linus Torvalds torva...@linux-foundation.org wrote:
On Fri, 4 Jun 2010, Ingo Molnar wrote:
This allows a task to 'exclude' other tasks that dont have low-latency
requirements. Crappy apps would have a large latency value, so they'd
be idled out when a privileged task sets
* Ingo Molnar mi...@elte.hu wrote:
- Create a 'deep idle' mode that suspends. This, if all constraints
are met, is triggered by the scheduler automatically: just like the other
idle modes are triggered currently. This approach fixes the wakeup
races because an incoming wakeup event
On Fri, 4 Jun 2010, Ingo Molnar wrote:
What you say is absolutely true, hence this would be driven via sched_tick()
+
TIF notifiers - i.e. only ever treat user-mode tasks as 'idle-able'. This can
be done with no overhead to the regular fastpaths.
The TIF notifier would be the one
On Thu, 3 Jun 2010, Linus Torvalds wrote:
so I'd like to see the opportunistc suspend thing think about CPU
offlining
Side note: one reason for me being somewhat interested in the CPU
offlining is that I think the Android kind of opportunistic suspend is
_not_ likely something I'd like
On Thu, 3 Jun 2010 19:26:50 -0700 (PDT)
Linus Torvalds torva...@linux-foundation.org wrote:
If the system is idle (or almost idle) for long times, I would
heartily recommend actively shutting down unused cores. Some CPU's
are hopefully smart enough to not even need that kind of software
On Thu, Jun 3, 2010 at 7:16 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Fri, 4 Jun 2010, Ingo Molnar wrote:
What you say is absolutely true, hence this would be driven via sched_tick()
+
TIF notifiers - i.e. only ever treat user-mode tasks as 'idle-able'. This can
be done
On Fri, 4 Jun 2010 01:23:02 +0200
Ingo Molnar mi...@elte.hu wrote:
Btw., i'd like to summarize the scheduler based suspend scheme proposed by
Thomas Gleixner, Peter Zijlstra and myself. I found no good summary of it in
the big thread, and there are also new elements of the proposal:
Hi
I
On Thu, 3 Jun 2010, Arjan van de Ven wrote:
And because there's then no power saving (but a performance cost), it's
actually a negative for battery life/total energy.
Including the UP optimizations we do (ie lock prefix removal)? It's
possible that I'm just biased by benchmarks, and it's
On Thu, Jun 3, 2010 at 4:23 PM, Ingo Molnar mi...@elte.hu wrote:
...
- Controlled auto-suspend: drivers (such as input) could on wakeup
automatically set the 'minimum wakeup latency' value of wakee tasks to a
lower value. This automatically prevents another auto-suspend in the near
101 - 191 of 191 matches
Mail list logo
