PM: Opportunistic suspend support.
in [Kernel]
|
Prev: direct-io: do not merge logically non-contiguous requests
Next: [PATCH] linux/elfcore.h: hide kernel functions
From: Rafael J. Wysocki on 26 May 2010 18:00 On Wednesday 26 May 2010, Alan Stern wrote: > On Tue, 25 May 2010, Dmitry Torokhov wrote: > > > > How is that not polling? If the user is holding down a key, the keypad > > > driver has to block suspend, and user space will try to suspend again > > > and again and again... > > > > > > > If your userpsace is that stupid - sure. However, you can: > > > > 1. Notify the suspend manager process that he rest of your userspace is > > busy handling keystrokes so that it does not try to suspend while there > > are events pending. > > > > 2. Wait a tiny bit after last application notified you that it finished > > processing events. > > This is more complicated than necessary. Arve is wrong; my suggested > design does not require polling. > > The reason is simple: When a user process initiates an opportunistic > suspend, you make it wait in an interruptible sleep until all the > kernel suspend blockers are released. No polling. If another user > thread decides in the meantime that it needs to block the suspend, it > sends a signal to the power manager process. > > In fact, other threads should signal the power manager process whenever > they want to block or unblock suspends. That way the power manager > process can spend all its time sleeping, without doing any polling. I still see an issue here. Namely, if the power manager is in user space and it's signaled to suspend, it has to ask the kernel to do that, presumably by writing something to a sysfs file. Then, if the kernel blocks the suspend, the power manager waits until the block is released. Now, it should go back and check if user space still doesn't block suspend and if so, wait until the block is released and start over. With all suspend blockers in the kernel this looping behavior is avoidable. > > So basically the difference is that with in-kernel suspend blockers, > > there is a tiny window where we haven't started the suspend yet but are > > about to the driver has a chance to prevent entire system from starting > > sleep. > > > > Without the blocker we may start suspending and will stop midcycle. We > > may be even better off in the end since we could leave some devices > > still powered down after aborting system-wide suspend. > > That's not so easy. The design of the PM core requires that when the > system wakes up from suspend (or from an aborted suspend attempt), all > devices should go to full-power-on. This is explained in section 6 of > Documentation/power/runtime_pm.txt. > > The decision over whether to use kernel-space suspend blockers vs. > aborting suspends when queues are non-empty comes down to a tradeoff: > > Suspend blockers involve a little more code (to create, > destroy, enable, and disable them) plus a little extra > runtime overhead each time an event occurs. (Some people > may object to this extra overhead, although so far nobody > in this discussion has done so.) > > Suspend blockers eliminate the extra overhead involved in > starting suspends that are just going to be aborted. > > Suspend blockers offer extra debugging and accountability > (the user can find out which subsystems are responsible for > keeping the system awake). > > Which way you think the tradeoff should go is a subjective decision. I > think that kernel suspend blockers are acceptable. I agree. 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: Rafael J. Wysocki on 26 May 2010 18:10 On Wednesday 26 May 2010, Matthew Garrett wrote: > On Wed, May 26, 2010 at 02:57:45PM +0200, Peter Zijlstra wrote: > > > I fail to see why. In both cases the woken userspace will contact a > > central governing task, either the kernel or the userspace suspend > > manager, and inform it there is work to be done, and please don't > > suspend now. > > Thinking about this, you're right - we don't have to wait, but that does > result in another problem. Imagine we get two wakeup events > approximately simultaneously. In the kernel-level universe the kernel > knows when both have been handled. In the user-level universe, we may > have one task schedule, bump the count, handle the event, drop the count > and then we attempt a suspend again because the second event handler > hasn't had an opportunity to run yet. We'll then attempt a suspend and > immediately bounce back up. That's kind of wasteful, although it'd be > somewhat mitigated by checking that right at the top of suspend entry > and returning -EAGAIN or similar. I still think it would cause a loop-alike behavior between the user space power manager and the kernel PM core to happen, because the power manager will always have to check the user space counter after a failing suspend attempt. 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: Alan Stern on 26 May 2010 18:20 On Wed, 26 May 2010, Rafael J. Wysocki wrote: > > The reason is simple: When a user process initiates an opportunistic > > suspend, you make it wait in an interruptible sleep until all the > > kernel suspend blockers are released. No polling. If another user > > thread decides in the meantime that it needs to block the suspend, it > > sends a signal to the power manager process. > > > > In fact, other threads should signal the power manager process whenever > > they want to block or unblock suspends. That way the power manager > > process can spend all its time sleeping, without doing any polling. > > I still see an issue here. Namely, if the power manager is in user space and > it's signaled to suspend, it has to ask the kernel to do that, presumably by > writing something to a sysfs file. Then, if the kernel blocks the suspend, the > power manager waits until the block is released. Now, it should go back and > check if user space still doesn't block suspend and if so, wait until the block > is released and start over. With all suspend blockers in the kernel this > looping behavior is avoidable. I must be missing something. In Arve's patch 1/8, if the system is in opportunistic suspend, and a wakeup event occurs but no suspend blockers get enabled by the handler, what causes the system to go back into suspend after the event is handled? Isn't that a loop of some sort? And even if it isn't, so what? What's wrong with looping behavior? Especially a loop that's as short as this one and spends almost all of its time sleeping. Think how much harder it would be to write programs if you weren't allowed to use any loops. :-) 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: Rafael J. Wysocki on 26 May 2010 18:20 On Wednesday 26 May 2010, Peter Zijlstra wrote: > On Wed, 2010-05-26 at 18:59 +0200, Pavel Machek wrote: > > On Wed 2010-05-26 18:28:28, Peter Zijlstra wrote: > > > On Wed, 2010-05-26 at 11:18 -0500, James Bottomley wrote: > > > > > Or make the suspend manager a C proglet and provide a JNI interface, > > > > > or whatever. > > > > > > > > It's a fairly large piece of code to try to rewrite in C, so I don't > > > > think that's feasible on a reasonable timescale. Android does have the > > > > concept of special sockets that can be used to communicate from less to > > > > more privileged processes (it has a very segmented runtime model), so > > > > these might be usable ... they have a drawback that they're essentially > > > > named pipes, so no multiplexing, but one per suspend influencing C > > > > process shouldn't be a huge burden. > > > > > > It wouldn't need to convert the whole Frameworks layer into C, just > > > enough to manage the suspend state. > > > > > > Anyway, I think there's been enough arguments against even the concept > > > of opportunistic/auto-suspend, and I for one will object with a NAK if > > > Rafael send this to Linus. > > > > It was submitted already. I tried to followup with NAK, but can't > > currently see it in the archive. > > It was apparently hidden on some funky list. Hiding pull requests is bad > enough, but hiding pull requests for contended features is just plain > wrong. It was not intentionally hidden. I think my mailer did that wrong because the CC list was too long or something like this. I surely intended to send it to the LKML, so sorry for the inconvenience. 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: Rafael J. Wysocki on 26 May 2010 18:30
On Wednesday 26 May 2010, Thomas Gleixner wrote: > On Wed, 26 May 2010, James Bottomley wrote: > > On Wed, 2010-05-26 at 19:01 +0200, Peter Zijlstra wrote: > > > On Wed, 2010-05-26 at 18:59 +0200, Pavel Machek wrote: > > > > On Wed 2010-05-26 18:28:28, Peter Zijlstra wrote: > > > > > On Wed, 2010-05-26 at 11:18 -0500, James Bottomley wrote: > > > > > > > Or make the suspend manager a C proglet and provide a JNI interface, > > > > > > > or whatever. > > > > > > > > > > > > It's a fairly large piece of code to try to rewrite in C, so I don't > > > > > > think that's feasible on a reasonable timescale. Android does have the > > > > > > concept of special sockets that can be used to communicate from less to > > > > > > more privileged processes (it has a very segmented runtime model), so > > > > > > these might be usable ... they have a drawback that they're essentially > > > > > > named pipes, so no multiplexing, but one per suspend influencing C > > > > > > process shouldn't be a huge burden. > > > > > > > > > > It wouldn't need to convert the whole Frameworks layer into C, just > > > > > enough to manage the suspend state. > > > > > > > > > > Anyway, I think there's been enough arguments against even the concept > > > > > of opportunistic/auto-suspend, and I for one will object with a NAK if > > > > > Rafael send this to Linus. > > > > > > > > It was submitted already. I tried to followup with NAK, but can't > > > > currently see it in the archive. > > > > You mean this one: > > > > https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025689.html > > > > ? > > > > > It was apparently hidden on some funky list. > > > > Sending a PM pull request to the PM list doesn't really strike me as the > > height of obfuscation. Plus almost everyone who objected was on the cc > > list. > > > > > Hiding pull requests is bad enough, but hiding pull requests for > > > contended features is just plain wrong. > > > > I don't think it's a conspiracy ... just standard operating procedure > > for this subsystem. I do think cc'ing lkml is good practise (having > > been yelled at for not doing that in the past) but it's certainly not > > universal practise. > > At least it would be good style for a topic which is As I said in another message, I intended to send the pull request to the LKML, but for some reason that didn't work. Perhaps that was my fault, so sorry for that, but I think the CC list contained people who had objections, so they easily could respond (adding the CC to the LKML). > 1) contended like this one > > 2) pushing an intrusive feature last minute which has been merged > into the pm tree barely two days ago. It had been discussed for a month before without any serious progress, though, so I simply had to do something to make things go. :-) > Darn, _we_ have to deal with that forever as it sets a crappy user > space ABI in stone. Well, I don't think it's _that_ bad, although it isn't nice either. The whole reason why it's there is because the Google people want to collect suspend blocker usage statistics, so that they can easily check how often applications block suspending. If we dropped the statistics part, the interface might be substantially simplified. Thanks, Rafael > > Thanks, > > tglx > > -- 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/ |