[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: mark gross on 28 May 2010 23:20 On Thu, May 27, 2010 at 11:06:23AM -0400, Alan Stern wrote: > If people don't mind, here is a greatly simplified summary of the > comments and objections I have seen so far on this thread: > > The in-kernel suspend blocker implementation is okay, even > beneficial. Only if they only block. You get into trouble when the in kernel un-block opperation triggers an implicit suspend. > > Opportunistic suspends are okay. > > The proposed userspace API is too Android-specific. > > More kernel mechanisms are needed for expressing processes' > latency requirements. True. --mgross > > The last one is obviously a longer-term issue, so let's ignore it for > now. That leaves as the only point of contention the userspace > suspend-blocker API. > > The proposal I made a couple of days ago removes this API and leaves > the other things (i.e., the in-kernel suspend blockers and > opportunistic suspend) intact. In place of the userspace > kernel-blocker API, Android would have to implement a power manager > process that would essentially juggle all the latency requirements in > userspace. > > Communication between the power manager process and the kernel would be > limited to adding a new "opportunistic" entry to /sys/power/state -- > something which could well be useful in its own right. Even if this > API turns out not to be good, it's simple enough that it could be > removed pretty easily. > > This answers Alan Cox's (and other's) desire not to implement a > questionable or special-purpose API. And it also answers Thomas's > desire to make scheduling decisions based on latency requirements > (although the answer is simply to punt all these decisions out of the > kernel and into userspace -- which is reasonable for now since the > alternative would require a long-term kernel development effort). > > Indeed, having a power manager thread may well turn out to be a useful > thing -- but even if it doesn't, this scheme minimizes the damage while > still allowing the Android platform to use a vanilla kernel with only > limited modifications to their userspace. > > Alan Stern > > _______________________________________________ > linux-pm mailing list > linux-pm(a)lists.linux-foundation.org > https://lists.linux-foundation.org/mailman/listinfo/linux-pm -- 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: Peter Zijlstra on 29 May 2010 04:00 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. -- 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: Peter Zijlstra on 29 May 2010 04:10 On Sat, 2010-05-29 at 00:18 +0200, Rafael J. Wysocki wrote: > On Friday 28 May 2010, Peter Zijlstra wrote: > > On Fri, 2010-05-28 at 00:50 +0100, Alan Cox wrote: > > > Today "idle" means "no task running" > > > > > > If you are prepared to rephrase that as "no task that matters is running" > > > what would need to answer ? > > > > I'm not sure we need or want to go there. > > > > Why not simply let upatedb block on its IO because its QoS policy tells > > us that its IO priority is idle. Therefore it will not avoid the IO > > device from going idle and indefinitely delaying servicing requests. > > > > When updatedb blocks, the runqueue becomes empty and we gain goodness. > > > > Or are we talking about the same thing? > > There may be apps that don't actually do I/O that we may want to be treated > that way too. > > Consider the following scenario. I have a purely computational task that's > running on my laptop in the background (say it's a folding(a)home or something > similar), but I only want it to run when (a) the box is on AC power and (b) > when user interface is "active" (the latter would have to be defined precisely, > but for the purpose of this thought experiment let's assume we have such a > definition). Then, I'd only like it to be regarded as runnable if (a) and (b) > both happen at the same time, but it can't block on I/O. Well, both folding(a)home and Seti will need to do some IO in order to get new data and report results, although the computational task might indeed take quite a while before it does so. Such tasks should listen to general environment hints, we already have battery power state exposed, make it use that information. The user interface is active can be gotten from X. The thing is, if its a well behaved app and listens to the environment hints, it will work as you want (could be done by policy knobs all-round). The only problem is dealing with apps that don't listen, those are considered bad/buggy and hence we don't particularly care if they don't function properly. For long-running computational tasks we will send a progression of SIGXCPU, SIGSTOP, SIGTERM and eventually SIGKILL if they keep violating policy. -- 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: Peter Zijlstra on 29 May 2010 04:20 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. 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. > 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. 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. The only abstraction that really makes sense in that view is idle states. -- 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: Florian Mickler on 29 May 2010 04:30
On Sat, 29 May 2010 02:42:35 +0300 Felipe Contreras <felipe.contreras(a)gmail.com> wrote: > On Fri, May 28, 2010 at 5:12 PM, Igor Stoppa <igor.stoppa(a)nokia.com> wrote: > > ext Brian Swetland wrote: > >> How is it flawed? �Serious question. > > > > I would avoid repeating all the good arguments given so far, but to make it > > short: > > > > * I believe runtime PM is a much better starting point (at least for the > > type of HW targeted at mobile devices) because it mimics an always-on system > > toward userspace, which requires less disruption in the way apps are > > designed > > I agree. > > If I understand correctly, if we have a perfect user-space that only > does work when strictly needed and trying to do it in bursts, then we > would be reaching the lowest power state, and there would be no need > for suspend. The problem is that Android's user-space is pretty far > from that, so they said "let's segregate user-space and go to lower > power mode anyway". This has already been mentioned (who knew?): Android doesn't want to depend on userspace for this. Cheers, Flo -- 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/ |