On Thu, May 27, 2010 at 11:08:06PM +0100, Alan Cox wrote:
This is I believe robust (and has been implemented on some non x86
boxes). It depends on not forcing running tasks into suspend. That is the
key.
We've already established that ACPI systems require us to force running
tasks into
On Thu, 27 May 2010 23:55:13 +0200
Rafael J. Wysocki r...@sisk.pl wrote:
On Thursday 27 May 2010, Alan Cox wrote:
If one works so does the other.
Not at all. The entire point of opportunistic suspend is that I don't
care is currently in TASK_RUNNABLE or has a timer that's due to
On Thu, 27 May 2010 23:09:49 +0100
Matthew Garrett mj...@srcf.ucam.org wrote:
On Thu, May 27, 2010 at 11:08:06PM +0100, Alan Cox wrote:
This is I believe robust (and has been implemented on some non x86
boxes). It depends on not forcing running tasks into suspend. That is the
key.
The kernel performs no explicit notification to userspace. With legacy
For a PC ACPI using type device /proc/acpi/events which wakes acpid which
wakes gnome-power-manager which wakes half the universe
Do we need a better more generic version of the events files - maybe but
thats a rather
On Thu, May 27, 2010 at 11:32:47PM +0100, Alan Cox wrote:
The kernel performs no explicit notification to userspace. With legacy
For a PC ACPI using type device /proc/acpi/events which wakes acpid which
wakes gnome-power-manager which wakes half the universe
No, there's no explicit
On Thu, May 27, 2010 at 11:23:57PM +0100, Alan Cox wrote:
On Thu, 27 May 2010 23:09:49 +0100
Matthew Garrett mj...@srcf.ucam.org wrote:
On Thu, May 27, 2010 at 11:08:06PM +0100, Alan Cox wrote:
This is I believe robust (and has been implemented on some non x86
boxes). It depends on
On Thursday 27 May 2010, Peter Zijlstra wrote:
On Thu, 2010-05-27 at 18:40 +0100, Matthew Garrett wrote:
On Thu, May 27, 2010 at 07:34:40PM +0200, Peter Zijlstra wrote:
we still need to be able to enter suspend while the system isn't idle.
_WHY_!?
Because if I'm running a kernel
On Thursday 27 May 2010, Matthew Garrett wrote:
On Thu, May 27, 2010 at 07:05:15PM +0100, Alan Cox wrote:
I'd prefer we avoided mixing them up. Everyone seems fairly happy with
the current operator ordered suspend behaviour I believe ?
No. The current mechanism can lose wakeup events.
On Thu, 27 May 2010 23:36:05 +0100
Matthew Garrett mj...@srcf.ucam.org wrote:
On Thu, May 27, 2010 at 11:23:57PM +0100, Alan Cox wrote:
On Thu, 27 May 2010 23:09:49 +0100
Matthew Garrett mj...@srcf.ucam.org wrote:
On Thu, May 27, 2010 at 11:08:06PM +0100, Alan Cox wrote:
This
Matthew:
Remind me why the idle/QOS power management approach won't work here.
If the difficulty is untrusted apps preventing the system from being
idle, why not assign them to QoS(NONE) as Thomas suggested?
If the difficulty is that some untrusted apps need to receive wakeup
events, why not
The approach with user space power manager suggested by Dmitry and Alan Stern
may work, but it still assumes some kind of suspend blockers to be present in
the kernel. If we reject that too, I wonder what approach Google is supposed
to use and still get the same battery life they get with
On Thursday 27 May 2010, Alan Cox wrote:
No, it's not. Forced suspend may be in response to hitting a key, but it
You are the only person here talking about 'forced' suspends. The rest of
us are talking about idling down and ensuring we are always in a state we
un-idle correctly.
may
On Fri, May 28, 2010 at 12:50:45AM +0100, Alan Cox wrote:
That's correct, but to me the Arve's goal is simply to maximize battery life
and he found experimentally that the longest battery life is achieved if
system suspend is used whenever the system doesn't need to be active (from
its
On Friday 28 May 2010, Alan Cox wrote:
That's correct, but to me the Arve's goal is simply to maximize battery life
and he found experimentally that the longest battery life is achieved if
system suspend is used whenever the system doesn't need to be active (from
its
user's
On Thu, May 27, 2010 at 4:50 PM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
That's correct, but to me the Arve's goal is simply to maximize battery life
and he found experimentally that the longest battery life is achieved if
system suspend is used whenever the system doesn't need to be active
On Thu, May 27, 2010 at 5:05 PM, Rafael J. Wysocki r...@sisk.pl wrote:
On Friday 28 May 2010, Alan Cox wrote:
The approach with user space power manager suggested by Dmitry and Alan
Stern
may work, but it still assumes some kind of suspend blockers to be present
in
the kernel. If we
On Fri, 28 May 2010, Rafael J. Wysocki wrote:
And the forced-suspend design relies on the fact that processes remain
frozen throughout. If we leave some processes unfrozen and one of them
somehow becomes runnable, that means we have to abort the forced
suspend before the process is
On Wed, 26 May 2010 14:24:30 +0200, Florian Mickler flor...@mickler.org wrote:
Because he is using a robust kernel that provides suspend blockers and
is preventing the vampire from sucking power?
Suspend blockers are only a flawed and indirect way to keep the vampire
from sucking.
Most
On Thu, May 27, 2010 at 3:23 PM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
On Thu, 27 May 2010 23:09:49 +0100
Matthew Garrett mj...@srcf.ucam.org wrote:
On Thu, May 27, 2010 at 11:08:06PM +0100, Alan Cox wrote:
This is I believe robust (and has been implemented on some non x86
boxes). It
On Thu, May 27, 2010 at 11:55:46PM +0100, Alan Cox wrote:
This started because the Android people came to a meeting that was put
together of various folks to try and sort of the big blockage in getting
Android and Linux kernels back towards merging.
I am interested right now in finding a
On Thu, May 27, 2010 at 3:55 PM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
This started because the Android people came to a meeting that was put
together of various folks to try and sort of the big blockage in getting
Android and Linux kernels back towards merging.
I am interested right now
On Thu, 2010-05-27 at 15:19 -0400, Alan Stern wrote:
On Thu, 27 May 2010, Peter Zijlstra wrote:
I still don't see how blocking applications will cause missed wakeups in
anything but a buggy application at worst, and even those will
eventually get the event when they unblock.
What
201 - 222 of 222 matches
Mail list logo
