[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: Rafael J. Wysocki on 28 May 2010 18:20 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. Thanks, 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 28 May 2010 18:30 On Friday 28 May 2010, Arve Hj�nnev�g wrote: > On Fri, May 28, 2010 at 1:44 AM, Florian Mickler <florian(a)mickler.org> wrote: > > On Thu, 27 May 2010 20:05:39 +0200 (CEST) > > Thomas Gleixner <tglx(a)linutronix.de> wrote: .... > > To integrate this with the current way of doing things, i gathered it > > needs to be implemented as an idle-state that does the suspend()-call? > > > > I think it is better no not confuse this with idle. Since initiating > suspend will cause the system to become not-idle, I don't think is is > beneficial to initiate suspend from idle. It is, if the following two conditions hold simultaneously: (a) Doing full system suspend is ultimately going to bring you more energy savings than the (presumably lowest) idle state you're currently in. (b) You anticipate that the system will stay idle for a considerably long time such that it's worth suspending. Thanks, 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: Felipe Contreras on 28 May 2010 19:50 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". If that's true, then this problem can be fixed in user-space, and in fact, it already is on N900. Good behaving applications are asynchronous, use g_timeout_add_seconds() to align bursts of work at the same second intervals, and don't do polls directly, but use GLib's mainloop. Same as in GNOME desktop. It seems there are other methods to align multiple processes for longer periods of time, but that code is closed and I can't find much information. > * QoS is closer to the apps pov: fps if it is a media player or a game, > transfer speed if it is a file manager, bandwidth if it is a network app, > etc > The app is required to express its opinion by using a format that it > understands better and is less system dependent. > Actually the kernel should only be concerned with 2 parameters at most for > any given operation: latency and bandwidth/throughput I think this information can be obtained dynamically while the application is running, and perhaps the limits can be stored. It would be pretty difficult for the applications to give this kind of information because there are so many variables. For example, an media player can tell you: this clip has 24 fps, but if the user is moving the time slider, the fps would increase and drop very rapidly, and how much depends at least on the container format and type of seek. A game or a telephony app could tell you "I need real-time priority" but so much as giving the details of latency and bandwidth? I find that very unlikely. Cheers. -- Felipe Contreras -- 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: Arve Hjønnevåg on 28 May 2010 20:50 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. > If you were to read Alan's latest posts he clearly outlines how you can > contain crappy apps. > 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. > A combination of weakening QoS guarantees (delaying wakeups etc.) > blocking on resources (delay servicing requests) and monitoring resource > usage (despite all that its still not idle) and taking affirmative > action (shoot it in the head). > > If we pose that a well behaved application is one that listens to the > environment hints and idles when told to, we can let regular power > management kick in and let deep idle states do their thing. > > If a bad application ignores those hints and manages to avoid getting > blocked on denied resources, we can easily spot it and promote an > attitude of violence toward it in the form of SIGXCPU, SIGSTOP, SIGTERM > and SIGKILL, possibly coupled with a pop-up dialog -- much like we get > today when we try to close a window and the app isn't responding. > > If we then also let the environment maintain a shitlist of crappy apps > (those it had to take affirmative action against) and maybe set up a > service that allows people to share their results, it provides an > incentive to the app developers to fix their thing. > > How is this not working? > 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. -- Arve Hj�nnev�g -- 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: Arve Hjønnevåg on 28 May 2010 21:20
2010/5/28 Rafael J. Wysocki <rjw(a)sisk.pl>: > On Friday 28 May 2010, Arve Hj�nnev�g wrote: >> On Fri, May 28, 2010 at 1:44 AM, Florian Mickler <florian(a)mickler.org> wrote: >> > On Thu, 27 May 2010 20:05:39 +0200 (CEST) >> > Thomas Gleixner <tglx(a)linutronix.de> wrote: > ... >> > To integrate this with the current way of doing things, i gathered it >> > needs to be implemented as an idle-state that does the suspend()-call? >> > >> >> I think it is better no not confuse this with idle. Since initiating >> suspend will cause the system to become not-idle, I don't think is is >> beneficial to initiate suspend from idle. > > It is, if the following two conditions hold simultaneously: > > (a) Doing full system suspend is ultimately going to bring you more energy > � �savings than the (presumably lowest) idle state you're currently in. > > (b) You anticipate that the system will stay idle for a considerably long time > � �such that it's worth suspending. > I still don't think this matters. If you are waiting for in interrupt that cannot wake you up from suspend, then idle is not an indicator that it is safe to enter suspend. I also don't think you can avoid any user-space suspend blockers by delaying suspend until the system goes idle since any page fault could cause it to go idle. Therefore I don't see a benefit in delaying suspend until idle when the last suspend blocker is released (it would only mask possible race conditions). -- Arve Hj�nnev�g -- 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/ |