[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 29 May 2010 11:10 On Sat, 29 May 2010, Brian Swetland wrote: > On Sat, May 29, 2010 at 7:10 AM, Alan Stern <stern(a)rowland.harvard.edu> wrote: > > If no such constraints are active, the QoS-based suspend blocks in an > > interruptible wait until the number of active QOS_EVENTUALLY > > constraints drops to 0. When that happens, it carries out a normal > > suspend-to-RAM -- except that it checks along the way to make sure that > > no new QoS constraints are activated while the suspend is in progress. > > If they are, the PM core backs out and fails the QoS-based suspend. > > > > Userspace suspend blockers don't exist at all, as far as the kernel is > > concerned. In their place, the Android runs a power-manager program > > that receives IPC requests from other processes when they need to > > prevent the system from suspending or allow it to suspend. The power > > manager's main loop looks like this: > > > > for (;;) { > > while (any IPC requests remain) > > handle them; > > if (any processes need to prevent suspend) > > sleep; > > else > > write "qos" to /sys/power/state; > > } > > The issue with this approach is that if userspace wants to suspend > while a driver is holding a QOS_EVENTUALLY constraint, it's basically > going to spin constantly writing "qos" and failing. No, no. If userspace wants to suspend while a driver is holding a QOS_EVENTUALLY constraint, the user process blocks in an interruptible wait state as described in the first paragraph above. > Could we have write(powerstate_fd, "qos",3) block until all > QOS_EVENTUALLY constraints are lifted or the system successfully > suspends and resumes or a signal arrives? That is basically what I originally wrote. > > The idea is that receipt of a new IPC request will cause a signal to be > > sent, interrupting the sleep or the "qos" write. > > Alternatively (to ipc), we could have a driver provide the same > suspendblock style interface to userspace and maps it to qos > constraints. If it's something we maintain out-of-tree, no worries. > The kernel side api is the bit that's the headache to maintain > multiple versions of drivers with and without, after all. Yep. The idea is that all this userspace-oriented part should be invisible to the vanilla kernel. > I'm sure Arve will weigh in on this later, but from what I can see it > certainly seems like this model provides us with the functionality > we're looking for, provided the issue with > spinning-while-waiting-for-drivers-to-release-constraints is sorted > out. I'm more concerned about how the other kernel developers will react. 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: Brian Swetland on 29 May 2010 11:20 On Sat, May 29, 2010 at 8:03 AM, Alan Stern <stern(a)rowland.harvard.edu> wrote: > On Sat, 29 May 2010, Brian Swetland wrote: >> On Sat, May 29, 2010 at 7:10 AM, Alan Stern <stern(a)rowland.harvard.edu> wrote: >> > If no such constraints are active, the QoS-based suspend blocks in an >> > interruptible wait until the number of active QOS_EVENTUALLY >> > constraints drops to 0. When that happens, it carries out a normal >> > suspend-to-RAM -- except that it checks along the way to make sure that >> > no new QoS constraints are activated while the suspend is in progress. >> > If they are, the PM core backs out and fails the QoS-based suspend. >> >> The issue with this approach is that if userspace wants to suspend >> while a driver is holding a QOS_EVENTUALLY constraint, it's basically >> going to spin constantly writing "qos" and failing. > > No, no. If userspace wants to suspend while a driver is holding a > QOS_EVENTUALLY constraint, the user process blocks in an interruptible > wait state as described in the first paragraph above. Oops -- I misread the first paragraph. The behavior you described is indeed what I would want. 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: James Bottomley on 29 May 2010 12:20 On Sat, 2010-05-29 at 10:10 +0200, Peter Zijlstra wrote: > On Fri, 2010-05-28 at 17:43 -0700, Arve Hjønnevåg wrote: > > On Fri, May 28, 2010 at 12:11 AM, Peter Zijlstra <peterz(a)infradead.org> wrote: > > > On Fri, 2010-05-28 at 00:31 -0400, tytso(a)mit.edu wrote: > > >> Keep in mind, though, that a solution which is acceptable for Android > > >> has to include making sure that crappy applications don't cause the > > >> battery to get drained. There seem to be some people who seem > > >> adamently against this requirement. > > > > > > Again, Alan, Thomas and myself don't argue against that, what we do > > > however argue against is suspend running apps as a form of power > > > management. > > > > > > > You seem to argue that android is not allowed to use suspend because > > the hardware we have shipped on can enter the same power state from > > idle. From my point of view, since we need to support suspend on some > > hardware we should be allowed to leverage this solution on the better > > hardware platforms as well if it improves our battery life. > > Correct, I strongly oppose using suspend. Not running runnable tasks is > not a sane solution. Look, this is getting into the realms of a pointless semantic quibble. The problem is that untrusted tasks need to be forcibly suspended when they have no legitimate work to do and the user hasn't authorised them to continue even if the scheduler sees them as runnable. Whether that's achieved by suspending the entire system or forcibly idling the tasks (using blocking states or freezers or something) so the scheduler can suspend from idle is something to be discussed, but the net result is that we have to stop a certain set of tasks in such a way that they can still receive certain external events ... semantically, this is equivalent to not running runnable tasks in my book. (Perhaps this whole thing is because the word runnable means different things ... I'm thinking a task that would consume power ... are you thinking in the scheduler R state?) Realistically, the main thing we need to do is stop timers posted against the task (which is likely polling in a main loop, that being the usual form of easy to write but power crazy app behaviour) from waking the task and bringing the system out of suspend (whether from idle or forced). > If current hardware can't cope, too friggin bad, get better hardware. > > But the truth is, all your OMAP phones really can deal with it. That's rubbish and you know it. We do software workarounds for hardware problems all the time ... try doing a git grep -i errata in arch x86, or imagine a USB subsystem that only supported sane standards conforming devices: that would have an almost zero intersect with the current USB device market. The job of the kernel is to accommodate hardware as best it can ... sometimes it might not be able to, but most of the time it does a pretty good job. The facts are that C states and S states are different and are entered differently. For some omap hardware, the power consumption in the lowest C state (with all the ancillary power control) is the same as S3, that's fine, suspend from idle works as well as suspend to ram modulo bad apps. For quite a lot of MSM hardware, the lowest C state power consumption is quite a bit above S3. It's not acceptable to tell those people "tough, your battery runs out in 30 minutes because you bought the wrong hardware". We have to figure out how to get to S3 ... whether this is from idle or some other mechanism is again a discussion point, but not doing it is not an option. > > I have not seen any suggestions for how to deal with all our > > interprocess dependencies when pausing a subset of processes. Without > > a solution to that we can only pause a subset of the processes we want > > to pause. > > Do not 'pause' processes and you don't have the problem, make them stop > on their own accord or kill them if they dont listen.. who cares about > ill-behaved apps anyway? > > But really, if you want a more detailed answer, you need to provide more > detail on these problems. > > If you want to allow an untrusted app to provide a dependency for a > trusted app, you've lost and I don't care. > > Trusted apps should be well behaved, otherwise there really is no point. > > > These solutions do not allow us to use suspend. They may get us closer > > to the power consumption we get from suspend on the good hardware or > > even surpass it, but we still need suspend on some hardware, and we > > would get event better results by using these solutions in addition to > > suspend compared to using them instead of suspend. > > Not using suspend is exactly the point. As Alan has argued, propagating > suspend blockers up into all regions of userspace will take much longer > than fixing the hardware. Strange, that's not what I heard as the possible solution. I thought he was advocating expressing the kernel side of suspend blockers as QoS constraints. Once we have QoS constraints correctly done in the kernel, userspace still has to express its requirements. If the requirements are static, then they can be done from policy files or in some other static way but if they're dynamic, they'll still have to be in the applications ... in about the same places the android wakelocks are. > You got to realize this is about Linux as a whole, I really don't care > one whit about the specific Android case. We want a solution that is > generic enough to solve the power consumption problem and makes sense on > future hardware. I don't think anyone disagrees with this. As long as we find a long term solution that satisfies the android case, everyone will be happy. > The only abstraction that really makes sense in that view is idle > states. James -- 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: James Bottomley on 29 May 2010 12:30 On Sat, 2010-05-29 at 12:42 +0200, Peter Zijlstra wrote: > On Sat, 2010-05-29 at 11:04 +0200, Florian Mickler wrote: > > On Sat, 29 May 2010 00:11:32 +0200 > > "Rafael J. Wysocki" <rjw(a)sisk.pl> wrote: > > > > > > > > Having reconsidered the suspend blockers idea I came to the conclusion that > > > in fact it was a workaround for three different problems. > > > > But it is also a change of paradigm. The scheduler should strive to > > have the system idle as long as possible to conserve battery. And > > everything that does not serve the purpose of the device has to be > > considered as not worth running, except if there are other > > purpose-fullfilling tasks to run anyway. > > No the purpose of the scheduler is to run tasks when they are runnable. > Not to second guess whatever caused them to become runnable. I still think there is a semantic issue here ... see other email. > If you start to randomly not run tasks, the inversion chaos that ensues > is terrible. As a sweeping statement, I disagree because you're explicitly saying we can't solve the actual problem. If you're saying the scheduler shouldn't do this and something external has to make the tasks idle somehow first, I agree. > You can apply the regular means of alleviating that and > that entails adding *-inheritance to all blockable resources. The -rt > patch set is doing that in part. So as a mechanism for idling tasks, this looks possible. I don't like it from a theoretical viewpoint because it can't idle cpu bound tasks. I'd like a solution that solved all of the problem, not just all except stuff we think probably won't happen on a phone because experience tells me that partial solutions eventually turn up gotchas down the road. > You really need to make applications not want to run and block on their > own volition (in a resource free point) and otherwise make them block on > something forcefully and disregard any malfunctioning that would result > from that, and in extreme cases terminate (releasing all resources). > > But really Android shouldn't even need kernel support to do all this, > since its hosted on this massive middle-ware that intercepts everything, > called a Java Virtual Machine. The timers for a polling main loop have to be stopped ... this isn't possible with the current interface today, therefore we have to have kernel changes in some form. > Now, all I'm interested in is providing interfaces from the kernel where > needed, so that userspace can be optimally frugal with power usage, and > can monitor/contain badly behaving tasks. So, that sounds like the goal of just about everyone on the thread. > If Android is so set in its ways that they don't want to adopt (like > saying Android requires suspend for power management) then they can go > their own merry way and I'm not interested anymore (it would be a shame > though). They haven't actually said this. They've said they've implemented opportunistic suspend because it solves two problems: power savings for devices whose C states don't go as low as S3 and forced idling of tasks. Their main goal is extending battery life per charge, and what I've heard them say is any solution that does this is fine ... as long as the life per charge is as good as (or preferably better than) their current implementation ... I don't think that's unreasonable, and I think it might be achievable with some of the ideas in this thread. James -- 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 29 May 2010 16:20
On Saturday 29 May 2010, Peter Zijlstra wrote: > On Fri, 2010-05-28 at 23:44 +0200, Rafael J. Wysocki wrote: > > Consider updatedb or another file indexing ... thing on a laptop. I certainly > > don't want anything like this to run and drain my battery, even if it has > > already been started when the machine was on AC power. Now, of course, > > I can kill it, but for that I need to notice that it's running and it presumably > > might have done some job already and it would be wasteful to lose it. > > It would be quite nice if that app was not regarded as runnable when the > > system was on battery power. > > How will a ionice on steriods that will defer servicing IO when the IO > system QoS limit doesn't meet the updatedb process's level is too low, > not solve this? > > In that case the updatedb process will simply block on IO, will hence > not be runnable and thus not drain your battery. It will only work for apps that use I/O, but there may be purely CPU-bound ones that need that kind of approach too. -- 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/ |