Attempted summary of suspend-blockers LKML thread, take three
in [Kernel]
|
From: Felipe Contreras on 11 Aug 2010 20:20 On Thu, Aug 12, 2010 at 1:12 AM, Paul E. McKenney <paulmck(a)linux.vnet.ibm.com> wrote: > On Wed, Aug 11, 2010 at 11:00:42PM +0300, Felipe Contreras wrote: >> On Wed, Aug 11, 2010 at 3:42 AM, Paul E. McKenney >> <paulmck(a)linux.vnet.ibm.com> wrote: >> > On Tue, Aug 10, 2010 at 09:38:49AM +0100, Alan Cox wrote: >> >> You may also wish to review the earlier parts of the discussion where it >> >> was explicitly stated by several developers that they were using >> >> "suspend" type modes as power states already and not using suspend >> >> blockers. So it's being done, today on ARM and your statement is directly >> >> contradicting the code. Modern ARM processors and x86 MID devices can >> >> suspend and resume extremely fast (fast enough that the fact Linux x86 >> >> rewriting all the SMP alternatives on suspend/resume is a measurable >> >> problem). If this same property doesn't end up on big PC boxes in time >> >> then I'd be very surprised. At that point the openoffice with suspend >> >> blockers or oracle with suspend blockers question becomes rather relevant. >> > >> > Here is the list of properties distinguishing idle from suspend: >> > >> > 1. Idle states are entered by a given CPU only there are no runnable >> > tasks for that CPU. In contrast, opportunistic suspend can >> > halt the entire system even when there are tasks that are ready, >> > willing, and able to run. (But please note that this might not >> > apply to real-time tasks.) >> >> But if there are no runnable tasks (which is the target), they behave the same. > > And if there are runnable tasks, then then don't behave the same. Unless they have blocked suspend. Anyway, Alan was picturing a hypothetical point in time when x86 can suspend/resume as fast as ARM, and thus the question of whether or not to enable suspend-blockers in a system that runs openoffice becomes relevant. If applications have been fixed by that time to not wake the system unnecessarily, as many of them have already been tanks to tools like powertop, then suspend-blockers would not make that much of a difference, therefore the effort required to implement suspend-blockers properly on all applications in the system, including openoffice might not be worth the gain. > Apparently different people in this debate have different targets. I remember clearly Android people explaining that dynamic PM is orthogonal to suspend-blockers; if a suspend is blocked, you still want dynamic PM to reach the lower power state. Therefore the target of not having unneeded runnable tasks is shared by Android folks. >> > 2. There can be a set of input events that do not bring the system >> > out of suspend, but which would bring the system out of idle. >> > Exactly which events are in this set depends both on hardware >> > capabilities and on the platform/application policy. For example, >> > on one of the Android-based smartphones, touchscreen input is >> > ignored when the system is suspended, but is handled when idle. >> >> And in N900 touching the screen doesn't bring the device out of idle, >> I guess because it's off. > > As long as touching the N900 screen doesn't bring the device out of > suspend, its behavior is not a counterexample to #2 above. You said "there can be a set of input events that do not bring the system out of suspend, but which would bring the system out of idle". There's no suspend (in the Android sense) in N900, only idle, and the events that bring N900 out of idle can be mapped to the set of events that bring Android out of suspend. IOW. Alan wasn't talking about idle vs suspend on the same device, he was talking about opportunistic suspend vs dynamic PM. >> > 3. The system comes out of idle when a timer expires. In contrast, >> > timers might or might not bring the system out of suspend, >> > depending on both hardware capabilities and platform/application >> > policy. >> >> Isn't this solved by range timers? > > Ahem. This is a list of differences between idle and suspend, not > a list of problems to be solved. But to answer your question, if a > timer does not bring a given device out of suspend, then a range timer > is not likely to, either. Don't get me wrong, I do believe that range > timers have an important part to play in the energy-efficiency arena, > but I have not been convinced that they are any kind of silver bullet. Certainly, but the context is the set of differences that would aid in the decision of whether or not to go for suspend-blockers in a general purpose system where openoffice would run. >> > 4. Suspend generally forces devices to go into their low-power >> > states immediately. In contrast, idle generally leaves unused >> > devices at full power, relying on timers to shut down these >> > devices. Idle thus has shorter average wakeup latencies, but >> > worse energy efficiency. >> >> Only if you make these assumptions >> 1) All the applications use suspend-blockers only when they absolutely must >> 2) The user has given the right applications the right access > > You believe that these assumptions are unreasonable? Compared to the > assumption that all applications are carefully written to conserve power? > If so, on what grounds? No, I think both (for opportunistic suspend and dynamic PM) are completely reasonable. But think again; if you have the assumptions met on both, then both work fine, if you don't meet them, then both don't work correctly. My point is that suspend-blockers don't magically reduce power usage, just like dynamic PM, it depends on what user-space actually does. You made it look as it *always* reached better energy efficiency. > It seems to me that the same social-engineering approaches work in > both cases. Yes, but if dynamic PM works as advertised, you don't need opportunistic suspend. >> If not, you'll see much worst energy efficiency. So in theory maybe, >> but in practice you can't say that. > > Really? What makes you say that? For starters an application might be holding the wakelock more than it should, also, an application might miss a timer due to not having PM permissions to hold the lock, and thus might need an expensive initialization when it runs again. -- 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: Felipe Contreras on 11 Aug 2010 20:30 On Thu, Aug 12, 2010 at 1:28 AM, Paul E. McKenney <paulmck(a)linux.vnet.ibm.com> wrote: > On Wed, Aug 11, 2010 at 10:18:51PM +0300, Felipe Contreras wrote: >> On Mon, Aug 9, 2010 at 9:16 PM, Paul E. McKenney >> <paulmck(a)linux.vnet.ibm.com> wrote: >> > But wouldn't an office suite run as a power-oblivious application on an >> > Android device? After all, office applications do not need to run when >> > the screen is turned off, so these the applications do not need to use >> > suspend blockers. >> >> Ideally the system would be suspended even when the screen is on. If >> there are no "trusted" applications running at the same time, then >> openoffice wouldn't load at all. Right? > > My understanding is that Android systems in fact do not suspend when > the screen is on, and that most (perhaps all) other systems do not > opportunistically suspend at all. There has been some speculation about > what a hypothetical Android having a non-volatile display might do, > but as far as I know, this is just speculation. I have a desktop system in mind. If opportunistic suspend is only triggered when the display is off, then it's no good for normal usage, and therefore dynamic PC needs to get its act together... specially for laptops. -- 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: Felipe Contreras on 11 Aug 2010 20:50 On Thu, Aug 12, 2010 at 1:12 AM, Brian Swetland <swetland(a)google.com> wrote: > On Wed, Aug 11, 2010 at 3:03 PM, Felipe Contreras > <felipe.contreras(a)gmail.com> wrote: >> This is what I'm talking about when I say multi-tasking, Android >> certainly doesn't have anything remotely like that: >> http://www.youtube.com/watch?v=7emvUBpEkbU > > Home + pick app -> switch to the app in whatever state it was in. If the app stops running, that's *fake* multi-tasking, and doesn't match my experience; I can't remember the details, but I tested it on a Nexus One, and the item I was looking at was gone, I had to scroll again. Also, I cannot go to last.fm on the browser, play some music, and do other stuff at the same time, can I? Anyway, what you do in Android is your problem. The point is that in Linux we need good PM *with* multi-tasking (not really an argument against opportunistic suspend, I think, but a clarification from Ted's comment) -- 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: Paul E. McKenney on 11 Aug 2010 21:10 On Thu, Aug 12, 2010 at 03:28:00AM +0300, Felipe Contreras wrote: > On Thu, Aug 12, 2010 at 1:28 AM, Paul E. McKenney > <paulmck(a)linux.vnet.ibm.com> wrote: > > On Wed, Aug 11, 2010 at 10:18:51PM +0300, Felipe Contreras wrote: > >> On Mon, Aug 9, 2010 at 9:16 PM, Paul E. McKenney > >> <paulmck(a)linux.vnet.ibm.com> wrote: > >> > But wouldn't an office suite run as a power-oblivious application on an > >> > Android device? �After all, office applications do not need to run when > >> > the screen is turned off, so these the applications do not need to use > >> > suspend blockers. > >> > >> Ideally the system would be suspended even when the screen is on. If > >> there are no "trusted" applications running at the same time, then > >> openoffice wouldn't load at all. Right? > > > > My understanding is that Android systems in fact do not suspend when > > the screen is on, and that most (perhaps all) other systems do not > > opportunistically suspend at all. �There has been some speculation about > > what a hypothetical Android having a non-volatile display might do, > > but as far as I know, this is just speculation. > > I have a desktop system in mind. If opportunistic suspend is only > triggered when the display is off, then it's no good for normal usage, > and therefore dynamic PC needs to get its act together... specially > for laptops. If I understand you correctly, you are saying that both opportunistic suspend and dynamic power control should be used together, with dynamic power control being used for short non-busy periods (as in between keystrokes) and opportunistic suspend being used for longer non-busy periods (as in while grabbing a coffee). That combination of usage sounds promising to me. That said, I don't know that anyone has really sat down and thought through how one might apply suspend blockers to a desktop system. I suspect that there are several ways to go about it. Thanx, Paul -- 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 11 Aug 2010 21:10
On Wed, Aug 11, 2010 at 5:46 PM, Felipe Contreras <felipe.contreras(a)gmail.com> wrote: > On Thu, Aug 12, 2010 at 1:12 AM, Brian Swetland <swetland(a)google.com> wrote: >> On Wed, Aug 11, 2010 at 3:03 PM, Felipe Contreras >> <felipe.contreras(a)gmail.com> wrote: >>> This is what I'm talking about when I say multi-tasking, Android >>> certainly doesn't have anything remotely like that: >>> http://www.youtube.com/watch?v=7emvUBpEkbU >> >> Home + pick app -> switch to the app in whatever state it was in. > > If the app stops running, that's *fake* multi-tasking, and doesn't > match my experience; I can't remember the details, but I tested it on > a Nexus One, and the item I was looking at was gone, I had to scroll > again. That'd be surprise. Last I checked I was able to launch 40-50 apps on N1 before we even started getting low on memory and the system won't kill apps off unless we completely bottom out on memory. It's possible that some app might do the wrong thing when going to the background and back to the foreground but that'd be an app bug. > Also, I cannot go to last.fm on the browser, play some music, and do > other stuff at the same time, can I? I'm not sure off the top of my head if the browser will keep music/flash playing on pages when it's not the foreground app, but you can certainly run something like Pandora (or a number of other streaming music apps) in the background and play streaming music while you do other stuff. There's no reason the browser *couldn't* do this as well. > Anyway, what you do in Android is your problem. The point is that in > Linux we need good PM *with* multi-tasking (not really an argument > against opportunistic suspend, I think, but a clarification from Ted's > comment) Well I'm glad we agree that multitasking and PM are important. 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/ |