[PATCH 0/8] Suspend block api (version 8)
in [Kernel]
|
Prev: [ANN] Linux Security Summit 2010 - Announcement and CFP
Next: [PATCH 4/8] PM: suspend_block: Add debugfs file
From: Alan Stern on 27 May 2010 15:20 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 seems to be the confusion? During forced suspend, applications are block because they are frozen. When an event occurs, the application is notified somehow. But it can't respond because it is frozen. Hence the event remains sitting in a kernel queue and the system goes ahead and suspends anyway. The application doesn't get thawed until the system wakes up at some indefinite time in the future. Alan Stern -- 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: Alan Cox on 27 May 2010 15:30 > Rather than continue going around in circles, let's agree that what the > Android people want is a new version of forced suspend -- not a I don't think this is true. I think that is the root of the problem. I don't disagree with the user experience they are trying to create or the fact something is needed to make it possible (if it turns out we can't already do it). Forced suspend is sticking stuff in running state into suspend Power management models (such as Thomas ARM box) which we know work are 'when nothing is running' into suspend. So for me the real question on that side of this specific case is 'how do you make sure those tasks are idle when you need them to be' QoS ? Spanking them from user space ? Drivers enforcing policy elements by blocking tasks ? Alan -- 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: Alan Stern on 27 May 2010 15:30 On Thu, 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 build in a tmpfs and I hit the sleep > > key, I need to go to sleep. Blocking processes on driver access isn't > > sufficient. > > But that's a whole different issue. I agree that a forced suspend for > things like that make sense, just not for power managing a running > system. Why not? Or rather, why shouldn't it? > PC style hardware like that doesn't wake up from suspend for > funny things like a keypress either (good thing too). Yes it does. If I close the lid of my laptop, wait a few seconds for it to suspend, then open the lid (which does not wake it up), and hit a key -- it wakes up. > Anyway all that already works (more or less), so I don't see the > problem. The "less" part is the problem. It would be nice to have a forced suspend mode that is more dicriminating: Instead of activating immediately it would wait until all pending events were handled. Alan Stern -- 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: Alan Stern on 27 May 2010 15:40 On Thu, 27 May 2010, Alan Cox wrote: > > Rather than continue going around in circles, let's agree that what the > > Android people want is a new version of forced suspend -- not a > > I don't think this is true. I think that is the root of the problem. Of course it's true. Just ask Arve -- he wants opportunistic suspend and it _is_ a variant of forced suspend. Ergo he wants a new type of forced suspend. Maybe that's not what he _ought_ to want. Nevertheless, there are valid reasons for wanting it. > I don't disagree with the user experience they are trying to create or > the fact something is needed to make it possible (if it turns out we > can't already do it). > > Forced suspend is sticking stuff in running state into suspend > > Power management models (such as Thomas ARM box) which we know work are > 'when nothing is running' into suspend. > > So for me the real question on that side of this specific case is 'how > do you make sure those tasks are idle when you need them to be' > > QoS ? > Spanking them from user space ? > Drivers enforcing policy elements by blocking tasks ? Currently we use the freezer. But it is a blunt tool -- it freezes every user process. Also, it doesn't actually make processes unrunnable; it just arranges things so that when they do run, they immediately put themselves back to sleep. 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 allowed to run. Alan Stern -- 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 27 May 2010 15:40
On Thu, May 27, 2010 at 08:25:38PM +0100, Alan Cox wrote: > The scheduler can happily do this, the power management will also > recognize STOPPED processes as no impediment to suspend. But wakeup events won't be delivered to STOPped processes, and there's also the race of an application being in the middle of handling a wakeup event when you send it the signal. -- 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/ |