Attempted summary of suspend-blockers LKML thread
in [Kernel]
|
Prev: [PATCH 6/7] usb: iowarrior: fix misuse of return value of copy_to_user()
Next: Get Back To Me Immediately....
From: Matthew Garrett on 5 Aug 2010 09:50 On Wed, Aug 04, 2010 at 04:19:20PM -0700, david(a)lang.hm wrote: > only consider the activity of a subset of processes when deciding if we > should suspend or not. If the decision is to suspend, freeze everything. > > you (and many other people) are confusing what I've proposed (use cgroups > to indicate what processes to care about and what ones to not care about > when deciding to suspend/go to idle) with the prior cgroup proposal (use > cgroups to freeze a subset of tasks while leaving others runnable) The decision on whether or not to go to sleep isn't the difficult bit of this problem space. -- Matthew Garrett | mjg59(a)srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: david on 5 Aug 2010 10:10 On Thu, 5 Aug 2010, Matthew Garrett wrote: > On Wed, Aug 04, 2010 at 04:19:20PM -0700, david(a)lang.hm wrote: > >> only consider the activity of a subset of processes when deciding if we >> should suspend or not. If the decision is to suspend, freeze everything. >> >> you (and many other people) are confusing what I've proposed (use cgroups >> to indicate what processes to care about and what ones to not care about >> when deciding to suspend/go to idle) with the prior cgroup proposal (use >> cgroups to freeze a subset of tasks while leaving others runnable) > > The decision on whether or not to go to sleep isn't the difficult bit of > this problem space. but isn't that all that wakelocks do? affect the decision on whether or not to go to sleep. David Lang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Matthew Garrett on 5 Aug 2010 10:20 On Thu, Aug 05, 2010 at 07:07:06AM -0700, david(a)lang.hm wrote: > On Thu, 5 Aug 2010, Matthew Garrett wrote: >> The decision on whether or not to go to sleep isn't the difficult bit of >> this problem space. > > but isn't that all that wakelocks do? affect the decision on whether or > not to go to sleep. You could think of them that way, but it's not the useful aspect of them - that much could be implemented entirely in userspace. Wakelocks provide a mechanism for userspace to ensure that it's handled all received events before a system suspend takes place. -- Matthew Garrett | mjg59(a)srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Brian Swetland on 5 Aug 2010 10:30 On Thu, Aug 5, 2010 at 7:16 AM, Matthew Garrett <mjg59(a)srcf.ucam.org> wrote: > On Thu, Aug 05, 2010 at 07:07:06AM -0700, david(a)lang.hm wrote: >> On Thu, 5 Aug 2010, Matthew Garrett wrote: >>> The decision on whether or not to go to sleep isn't the difficult bit of >>> this problem space. >> >> but isn't that all that wakelocks do? affect the decision on whether or >> not to go to sleep. > > You could think of them that way, but it's not the useful aspect of them > - that much could be implemented entirely in userspace. Wakelocks > provide a mechanism for userspace to ensure that it's handled all > received events before a system suspend takes place. For userspace or the kernel -- some events may not require userspace intervention, but do require the kernel to stay awake long enough to finish chewing on them. Say perhaps a wifi irq comes in, the wifi driver/stack needs to process some beacon packets or whatnot. Brian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: david on 5 Aug 2010 10:30
On Thu, 5 Aug 2010, Matthew Garrett wrote: > On Wed, Aug 04, 2010 at 06:02:28PM -0700, Arve Hj?nnev?g wrote: > >> Which makes the driver and/or network stack changes identical to using >> wakelocks, right? > > I think we're resigned to the fact that we need to indicate wakeup > events in a manner that's pretty equivalent to wakelocks. The only real > issue is what the API looks like. Anyone who's still talking about > cgroups seems to be trying to solve a different problem. Ok, it is now sounding to me like there are two different (but somewhat related) purposes that wakelocks are being used for 1. deciding if the system should go to sleep now or not (what most of the discussion has been about) 2. narrowing the race between going to sleep and wakeup events. I'm not sure it's possible to completely eliminate the race, even with wakelocks there is some time between the time you last check if the wakelock is set and when the hardware finishes responding to your commands to go to sleep (Unless you can set a level-based interrupt that will wake you up as soon as you finish going to sleep) David Lang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |