Attempted summary of suspend-blockers LKML thread, take three
in [Kernel]
|
From: Matthew Garrett on 10 Aug 2010 10:20 On Tue, Aug 10, 2010 at 09:38:49AM +0100, Alan Cox wrote: > > situation you call out can occur with manual suspend-to-RAM already: > > the fact is that this is a design choice. You could indeed make a > > Losing data is a design choice ? The application set a timer, the OS > shouldn't be ignoring it in that situation. It might want to delay it, it > might want to warn the user its hogging things it shouldnt (powertop, > battery usage monitors in Android etc) So we should remove explicit system suspend from the kernel? > > Hmmm... Exactly which part do you consider flawed? Let's take it > > one sentence at a time. The devices that I know of that lack suspend > > blockers also lack opportunistic suspend. Therefore, all applications on > > such devices run as would an application that acquired a suspend blocker > > when it started and did not release that suspend blocker until it exited. > > Pretty straightforward. > > What do you mean by "opportunistic suspend", lots of systems drop into > lowest power states whenever they can. "Suspend is different" is a bit of > Android religion that I am dubious has any basis in reality as seen from > the application end of the universe. > > You may also wish to review the earlier parts of the discussion where it > was explicitly stated by several developers that they were using > "suspend" type modes as power states already and not using suspend > blockers. So it's being done, today on ARM and your statement is directly > contradicting the code. Modern ARM processors and x86 MID devices can > suspend and resume extremely fast (fast enough that the fact Linux x86 > rewriting all the SMP alternatives on suspend/resume is a measurable > problem). If this same property doesn't end up on big PC boxes in time > then I'd be very surprised. At that point the openoffice with suspend > blockers or oracle with suspend blockers question becomes rather relevant. There's a clear and absolute difference between system suspend and entering the same hardware state from the idle loop. That difference is that processes aren't scheduled until an explicit wakeup event occurs. Android is entirely capable of entering the same low power state at idle (it's done with a hardcoded idle loop on Qualcomm, cpuidle on omap), but if you have more than 0 scheduling wakeups a second then your power draw is going to be greater. I agree that we should be targetting 0 wakeups per second. I don't agree that it's realistic to insist that a use model that assumes imperfect software is an invalid use model. -- 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: Mark Brown on 10 Aug 2010 10:20 On Mon, Aug 09, 2010 at 11:24:53AM +0100, Alan Cox wrote: > > I have to worry about manually killing off applications when memory > > gets low, I actually thought it was incredibly sucky. It was a > > miniature, badly done laptop. > Likewise I thought the lack of proper multi-tasking apps in Android was > comically bad. Nice device completely wrecked by the inability to flip > between running apps each with their own screen - something that was old > tech in 1990. Rather beside the point for this thread and it's perhaps not so intuitive as it ought to be but holding down the home button should do what you're looking for here. -- 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 10 Aug 2010 10:30 > > Losing data is a design choice ? The application set a timer, the OS > > shouldn't be ignoring it in that situation. It might want to delay it, it > > might want to warn the user its hogging things it shouldnt (powertop, > > battery usage monitors in Android etc) > > So we should remove explicit system suspend from the kernel? Explicit suspend is user triggered - in the laptop case its a bit different. I don't btw like the fact that a laptop explicit suspend doesn't end up as a dbus "save data" and openoffice save (or it didn't last time I looked which is a while ago). > There's a clear and absolute difference between system suspend and > entering the same hardware state from the idle loop. That difference is > that processes aren't scheduled until an explicit wakeup event occurs. > Android is entirely capable of entering the same low power state at idle > (it's done with a hardcoded idle loop on Qualcomm, cpuidle on omap), but > if you have more than 0 scheduling wakeups a second then your power draw > is going to be greater. And nothing stops you also implementing a 'forced' suspend, although you can do that nicely by simply stopping the process group that contains the stuff you don't want to stop suspend and dropping into suspend when you idle. > I agree that we should be targetting 0 wakeups per second. I don't agree > that it's realistic to insist that a use model that assumes imperfect > software is an invalid use model. No argument. The question is what applications should be expressing to the kernel which is not tied to assumptions like 'suspend mode' and which is generic. We don't have xfs stuff for example splattered all over userspace and in lots of drivers - we have generic interfaces. That way user community A doesn't have to care about user community B's choices, and JFFS flash fs people don't offend big data centre people and vice versa. 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 Cox on 10 Aug 2010 10:40 Which reminds me. I forgot a very important way that user space signals the kernel as to its intents. The kernel can see whether code is sleeping by choice or sleeping because someone blocked it (eg a page fault). The kernel also knows a lot about the event being waited for (much more so in -rt than base). We don't capture all of that info but it seems it would advance progress in the right direction to do so better. 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: Matthew Garrett on 10 Aug 2010 11:00
On Tue, Aug 10, 2010 at 03:40:26PM +0100, Alan Cox wrote: > > > Losing data is a design choice ? The application set a timer, the OS > > > shouldn't be ignoring it in that situation. It might want to delay it, it > > > might want to warn the user its hogging things it shouldnt (powertop, > > > battery usage monitors in Android etc) > > > > So we should remove explicit system suspend from the kernel? > > Explicit suspend is user triggered - in the laptop case its a bit > different. I don't btw like the fact that a laptop explicit suspend > doesn't end up as a dbus "save data" and openoffice save (or it didn't > last time I looked which is a while ago). It's not inherently user triggered. Machines typically have an idle timeout that triggers suspend. This differs from the Android opportunistic suspend approach only in that the timeout is significantly larger, primarily due to the greater latency involved. > > There's a clear and absolute difference between system suspend and > > entering the same hardware state from the idle loop. That difference is > > that processes aren't scheduled until an explicit wakeup event occurs. > > Android is entirely capable of entering the same low power state at idle > > (it's done with a hardcoded idle loop on Qualcomm, cpuidle on omap), but > > if you have more than 0 scheduling wakeups a second then your power draw > > is going to be greater. > > And nothing stops you also implementing a 'forced' suspend, although you > can do that nicely by simply stopping the process group that contains the > stuff you don't want to stop suspend and dropping into suspend when you > idle. We've already had the discussion about this resulting in potential deadlocks if there's any intercommunication between the trusted and untrusted apps, and if untrusted apps can be the consumers of wakeup events then you still end up with the wake event race condition. If we want to avoid the case where system suspend can cause wakeup events to be lost, we're pretty much required to implement something like suspend blocks (and, in fact, Rafael's implementation of this is already mainline). > > I agree that we should be targetting 0 wakeups per second. I don't agree > > that it's realistic to insist that a use model that assumes imperfect > > software is an invalid use model. > > No argument. > > The question is what applications should be expressing to the kernel > which is not tied to assumptions like 'suspend mode' and which is generic. > > We don't have xfs stuff for example splattered all over userspace and in > lots of drivers - we have generic interfaces. That way user community A > doesn't have to care about user community B's choices, and JFFS flash fs > people don't offend big data centre people and vice versa. I wholeheartedly agree. But nobody has yet provided a generic approach to avoiding the loss of wakeup events, and that's an issue you can hit whenever you use full-system suspend - it's not a problem that's unique to Android. -- 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/ |