Attempted summary of suspend-blockers LKML thread, take three
in [Kernel]
|
From: Ted Ts'o on 11 Aug 2010 15:40 On Wed, Aug 11, 2010 at 07:57:32PM +0300, Felipe Contreras wrote: > Let's concentrate; Android is the only mobile platform that has > expressed interested in suspend blockers. UI applications in Android > are written specifically for Android. Period. > > Other platforms, such as MeeGo, rely on Qt API, not suspend blockers. I think you're wrong that this will be sufficient, but I've already stated my position before, namely that what you do when you only have 800mWh has very different performance/battery tradeoffs than when you have 94,000mWh batteries. One of the reasons why my mail archive for this discussion has over 1800 messages and is close to 10MB is that everyone keeps saying the same thing over and over again. So I'm not going to say it again. I was thinking that the only way we can tell is for us to go away and come back in two years, and we can see whether or not Meego is getting the same 200,000 activations per day that Android is, and maybe *then* people will understand. However, earlier today, I had a very productive conversation with an engineer from Nokia who has had many years of experience of doing power management for cell phones, and who is now trying to make Meego power efficient enough for cell phones, and he seemed to think that problem which suspend blockers or wakelocks are trying to solve was valid. I now believe that part of the problem is that is that many Meego folks only have an experience with Netbooks or Laptops, and don't appreciate that sometimes, when you make such a radical change in battery capacity to a mobile handset, things become qualitatively different, and not just quantitatively different. Put another way, a laptop has six hours of battery lifetime with 94,000 mWh worth of battery; a cell phone needs to be able to be usable over a 20-24 hour period of despite having a 800-1200 mWh battery --- and what you need do for these two are different. This is very similar to how trying to make a kernel scale to 512 NUMA nodes is quite different to trying make a kernel work with 4-8 SMP cpu's. Until you've actually tried doing it, you might think that all you have to do is just throw in a bunch of spinlocks and rw spinlocks. But it turns out it's a lot harder than that --- but it's very hard to convince someone who hasn't had that experience to understand why that is true. So it may very well be that we should just agree to disagree, and if there are one or more Nokia engineers who are interested in doing something that would help their cell phones (I will let them speak up and clarify their positions for themselves), that they work directly with those who agree that there _is_ a problem. At that point, we can either keep these patches out of tree, much like how the SGI Altix has patches that are needed so that the Linux kernel scales enough so it will even successfully complete its kernel initialization successfully. Or if there is consensus between people who are interested at Linaro (if any), Nokia (if any), and Android (if any), maybe we take this directly to Linus, and he can say yes or no. But for those who are unwilling to believe it isn't even a problem, I don't know that another 2000 e-mail messages, and another 10MB of mail archives, is going to achieve anything. Let's just agree to disagree. - Ted P.S. Just to make it clear, I am speaking only for myself, and not for the Android team and not for Google in any way, shape, or form. Nor was the person from Nokia who expressed to me his opinions was not necessarily expressing the opinions of Nokia or (obviously) Meego. -- 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: Mark Brown on 11 Aug 2010 15:50 On Wed, Aug 11, 2010 at 10:25:04PM +0300, Felipe Contreras wrote: > On Tue, Aug 10, 2010 at 7:45 AM, Paul E. McKenney > > Android is certainly where suspend blockers originated, and is to the best > > of my knowledge is still the only platform that uses them. ??But there is > > a first user of every new mechanism, and for some time that first user > > will by definition be the only user of that mechanism. ??So the fact > > that Android is most probably the only user of suspend blockers does > > not prove anything about whether or not suspend blockers are sensible. > No, it's the fact that *nobody* else has said: hey, that looks like a > good idea, we should use that in our mobile platform (or any > platform). I don't think lack of external adoption is a terribly useful data point either way at the minute. While the feature is controversial a lot of the OSs will probably hold off on it (because it's effort to handle out of tree stuff and folks are really busy) and there's not that many out there which support random externally written packages (which is the major push for exporting the feature to userspace) in the first place. -- 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 16:10 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. > 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. What devices do what on which circumstances on what platform is completely irrelevant. > 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? > 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 If not, you'll see much worst energy efficiency. So in theory maybe, but in practice you can't say that. -- 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 17:30 On Wed, Aug 11, 2010 at 10:31 PM, Ted Ts'o <tytso(a)mit.edu> wrote: > On Wed, Aug 11, 2010 at 07:57:32PM +0300, Felipe Contreras wrote: >> Let's concentrate; Android is the only mobile platform that has >> expressed interested in suspend blockers. UI applications in Android >> are written specifically for Android. Period. >> >> Other platforms, such as MeeGo, rely on Qt API, not suspend blockers. > > I think you're wrong that this will be sufficient, but I've already > stated my position before, namely that what you do when you only have > 800mWh has very different performance/battery tradeoffs than when you > have 94,000mWh batteries. One of the reasons why my mail archive for > this discussion has over 1800 messages and is close to 10MB is that > everyone keeps saying the same thing over and over again. So I'm not > going to say it again. Applications need to take smart decisions to save power based on a number of things: is the screen on? is the ear close to the speaker? is there a network available? is it a cellular connection? has the user decided to automatically disconnect from the network after certain time, or at night? etc. I think that, and range timers / ip heartbeat is enough. But that, as you say has been discussed before. Now, only Android has decided to use suspend blockers, that's a *fact*, and I wanted to narrow the discussion to Android in order to make it easier to understand that Android doesn't need suspend blockers, once we have agreed that, then I'd gladly discuss it's merits outside Android. > I was thinking that the only way we can tell is for us to go away and > come back in two years, and we can see whether or not Meego is getting > the same 200,000 activations per day that Android is, and maybe *then* > people will understand. Are you kidding? Even if MeeGo fails in being as popular as Android, that doesn't saying anything about whether suspend-blockers are sensible or not. Besides, there is also the possibility that Android people realize they don't need suspend-blockers. > However, earlier today, I had a very productive conversation with an > engineer from Nokia who has had many years of experience of doing > power management for cell phones, and who is now trying to make Meego > power efficient enough for cell phones, and he seemed to think that > problem which suspend blockers or wakelocks are trying to solve was > valid. So? I'm sure there's some people in Google that believe that suspend-blockers are not needed. > I now believe that part of the problem is that is that many Meego > folks only have an experience with Netbooks or Laptops, and don't > appreciate that sometimes, when you make such a radical change in > battery capacity to a mobile handset, things become qualitatively > different, and not just quantitatively different. Put another way, a > laptop has six hours of battery lifetime with 94,000 mWh worth of > battery; a cell phone needs to be able to be usable over a 20-24 hour > period of despite having a 800-1200 mWh battery --- and what you need > do for these two are different. Right. Nokia people only have experience with laptops. Surely my N900 lasts days because it's receiving energy from another dimension. > This is very similar to how trying to make a kernel scale to 512 NUMA > nodes is quite different to trying make a kernel work with 4-8 SMP > cpu's. Until you've actually tried doing it, you might think that all > you have to do is just throw in a bunch of spinlocks and rw spinlocks. > But it turns out it's a lot harder than that --- but it's very hard to > convince someone who hasn't had that experience to understand why that > is true. We are talking about user-space. > So it may very well be that we should just agree to disagree, and if > there are one or more Nokia engineers who are interested in doing > something that would help their cell phones (I will let them speak up > and clarify their positions for themselves), that they work directly > with those who agree that there _is_ a problem. Yeah, there is a problem, and the solution doesn't require suspend-blockers. > At that point, we can either keep these patches out of tree, much like > how the SGI Altix has patches that are needed so that the Linux kernel > scales enough so it will even successfully complete its kernel > initialization successfully. Or if there is consensus between people > who are interested at Linaro (if any), Nokia (if any), and Android (if > any), maybe we take this directly to Linus, and he can say yes or no. > > But for those who are unwilling to believe it isn't even a problem, I > don't know that another 2000 e-mail messages, and another 10MB of mail > archives, is going to achieve anything. Let's just agree to disagree. I argued to you that suspend-blockers are not required in Android, and suddenly you decide we should agree to disagree without arguing back? Well, suit yourself. I still maintain that suspend-blockers is just an expensive workaround, and in some cases actually degrades power consumption; the right solution is much more sophisticated. -- 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: Brian Swetland on 11 Aug 2010 17:40
On Wed, Aug 11, 2010 at 2:25 PM, Felipe Contreras <felipe.contreras(a)gmail.com> wrote: > Now, only Android has decided to use suspend blockers, that's a > *fact*, and I wanted to narrow the discussion to Android in order to > make it easier to understand that Android doesn't need suspend > blockers, once we have agreed that, then I'd gladly discuss it's > merits outside Android. On behalf of the Android folks, we don't agree with this. If you're going to wait until we suddenly change our minds, I think you're going to be in for a long wait. > I argued to you that suspend-blockers are not required in Android, and > suddenly you decide we should agree to disagree without arguing back? > Well, suit yourself. I still maintain that suspend-blockers is just an > expensive workaround, and in some cases actually degrades power > consumption; the right solution is much more sophisticated. Once "the right solution" exists and solves our problems, we'll certainly look into switching over to it. I've yet to see a proposal in all this arguing that appears to me to be an improvement over what we have today with suspend blockers. I find the "don't do what you're doing because someday, somebody will do it better" to be an uncompelling argument. Given your opinion that Android lacks multitasking (what? really?) and various other strange statements about the platform, I'm likely to be taking your suggestions with generous helping of skepticism. 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/ |