[PATCH 0/8] Suspend block api (version 6)
in [Kernel]
|
Prev: [PATCH 8/8] power_supply: Block suspend while power supply change notifications are pending
Next: [PATCH 7/8] Input: Block suspend while event queue is not empty.
From: Daniel Walker on 13 May 2010 16:40 On Thu, 2010-05-13 at 13:23 -0700, Tony Lindgren wrote: > * Matthew Garrett <mjg(a)redhat.com> [100513 13:03]: > > On Thu, May 13, 2010 at 01:00:04PM -0700, Tony Lindgren wrote: > > > > > The system stays running because there's something to do. The system > > > won't suspend until all the processors hit the kernel idle loop and > > > the next_timer_interrupt_critical() returns nothing. > > > > At which point an application in a busy loop cripples you. > > Maybe you could deal with the misbehaving untrusted apps in the userspace > by sending kill -STOP to them when the screen blanks? Then continue > when some event wakes up the system again. Couldn't you just use priorities (nice), or cgroups to deal with that? I'm sure there is a way to limit an apps runtime, so the system does go idle sometimes. > > I think we could implement your suggestion more easily by just giving > > untrusted applications an effectively infinite amount of timer slack, > > but it still doesn't handle the case where an app behaves excrutiatingly > > badly. > > Hmm, if you use timer slack then you still need to search through > the whole timer list instead of a smaller critical timer list. > Both ways sound doable though. There are deferrable timers already in Linux.. It seems like it would just be an extension of that. Daniel -- 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: Rafael J. Wysocki on 13 May 2010 17:20 On Thursday 13 May 2010, Matthew Garrett wrote: > On Thu, May 13, 2010 at 12:36:34PM -0700, Daniel Walker wrote: > > On Thu, 2010-05-13 at 20:11 +0100, Matthew Garrett wrote: > > > See feature-removal-schedule.txt. So far we have no indication that it's > > > going to be replaced, because nobody has actually suggested a working > > > way to do this better. If we had a concrete implementation proposal for > > > that then we'd be in a pretty different position right now. > > > > Ok, feature-removal-schedule.txt applies to everything tho. What your > > saying is that if this interface only last a short time it might take 6 > > months, if it last for a long time it would take longer. There's no easy > > way to know that Google is the only user after some amount of time > > passes. > > If the interface is there for a long time, it's because we haven't come > up with anything better. And if we haven't come up with anything better, > the interface deserves to be there. Moreover, the interface is already in use out-of-tree and that usage is actually _growing_, so we have a growing number of out-of-tree drivers that aren't megrgeable for this very reason. I don't see any _realistic_ way of solving this problem other than merging the opportunistic suspend. If anyone sees one, and I mean _realistic_ and _practically_ _feasible_, please tell me. Rafael -- 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: Tony Lindgren on 13 May 2010 17:20 * Matthew Garrett <mjg(a)redhat.com> [100513 13:29]: > On Thu, May 13, 2010 at 01:23:20PM -0700, Tony Lindgren wrote: > > * Matthew Garrett <mjg(a)redhat.com> [100513 13:03]: > > > On Thu, May 13, 2010 at 01:00:04PM -0700, Tony Lindgren wrote: > > > > > > > The system stays running because there's something to do. The system > > > > won't suspend until all the processors hit the kernel idle loop and > > > > the next_timer_interrupt_critical() returns nothing. > > > > > > At which point an application in a busy loop cripples you. > > > > Maybe you could deal with the misbehaving untrusted apps in the userspace > > by sending kill -STOP to them when the screen blanks? Then continue > > when some event wakes up the system again. > > And if that's the application that's listening to the network socket > that you want to get a wakeup event from? This problem is hard. I'd love > there to be an elegant solution based on using the scheduler, but I > really don't know what it is. Your system should wake up to an interrupt in that case. Then you have the trusted apps running that can decide if the untrusted apps should be continued or not. The key would be to have the basic apps behave and use the critical timers as needed. The advantage is that then you can do all the policy in the userspace and in a custom pm_idle function. Regards, Tony -- 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: Daniel Walker on 13 May 2010 17:20 On Thu, 2010-05-13 at 23:11 +0200, Rafael J. Wysocki wrote: > On Thursday 13 May 2010, Matthew Garrett wrote: > > On Thu, May 13, 2010 at 12:36:34PM -0700, Daniel Walker wrote: > > > On Thu, 2010-05-13 at 20:11 +0100, Matthew Garrett wrote: > > > > See feature-removal-schedule.txt. So far we have no indication that it's > > > > going to be replaced, because nobody has actually suggested a working > > > > way to do this better. If we had a concrete implementation proposal for > > > > that then we'd be in a pretty different position right now. > > > > > > Ok, feature-removal-schedule.txt applies to everything tho. What your > > > saying is that if this interface only last a short time it might take 6 > > > months, if it last for a long time it would take longer. There's no easy > > > way to know that Google is the only user after some amount of time > > > passes. > > > > If the interface is there for a long time, it's because we haven't come > > up with anything better. And if we haven't come up with anything better, > > the interface deserves to be there. > > Moreover, the interface is already in use out-of-tree and that usage is > actually _growing_, so we have a growing number of out-of-tree drivers that > aren't megrgeable for this very reason. Why can't we merge the drivers? Drivers are just drivers, they don't need this to get merged. (They need it to work with Android) Daniel -- 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: Rafael J. Wysocki on 13 May 2010 17:20
On Thursday 13 May 2010, Tony Lindgren wrote: > * Alan Stern <stern(a)rowland.harvard.edu> [100513 07:11]: > > On Wed, 12 May 2010, Paul Walmsley wrote: > > > > > Hello, > > > > > > Some general comments on the suspend blockers/wakelock/opportunistic > > > suspend v6 patch series, posted here: > > > > > > https://lists.linux-foundation.org/pipermail/linux-pm/2010-April/025146.html > > > > > > The comments below are somewhat telegraphic in the interests of > > > readability - more specific comments to follow in later E-mails. I am > > > indebted to those of us who discussed these issues at LPC last year and > > > ELC this year for several stimulating discussions. > > > > > > There are several general problems with the design of opportunistic > > > suspend and suspend-blocks. > > > > > > 1. The opportunistic suspend code bypasses existing Linux kernel code, > > > such as timers and the scheduler, that indicates when code > > > needs to run, and when the system is idle. > > > > Whoa! That's not my understanding at all. > > > > As I see it, opportunistic suspend doesn't bypass any code that isn't > > already bypassed by the existing suspend code. Users can do > > > > echo mem >/sys/power/state > > > > whenever they want, without regard to kernel timers and the scheduler > > (other than the fact that the user's thread must be running in order to > > carry out the write, of course). > > The difference between echo mem > /sys/power/state and suspend blocks > is that with suspend blocks the system keeps running. Care to elaborate? Rafael -- 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/ |