Attempted summary of suspend-blockers LKML thread, take three
in [Kernel]
|
From: Ted Ts'o on 12 Aug 2010 14:30 On Thu, Aug 12, 2010 at 07:46:03PM +0300, Felipe Contreras wrote: > All the Android community had to do is push the drivers *without* > suspend blockers, then the Android kernel wouldn't be so different and > thus wouldn't be considered a fork. AFAIU the kernel side wakelocks > are already in the kernel, so there's no excuse not to merge the > drivers. What's there is not good enough, because it's missing the statistics and reporting so that badly behaved kernel and userspace drivers that take wakelocks can be found. I have a similar problem with the whole pm_qos subsystem, as I've said earlier. If some badly behaved application claims to want 0us wireless latency, and keeps the radio on all the time, there is no way for me to find out which is the badly behaved application --- even though I'm the owner of the laptop, and at the end of the day *I* should be able to say, no, battery lifetime is more important than what the application might think is its "minimum wireless latency". Not only can I not override the application, I can't even find out which application is at fault! ***FAIL*** In some ways, this is exactly the same problem as the "which badly Maemo application is causing my causing my N770 to have its battery laptop drop in half?". - Ted -- 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 12 Aug 2010 14:50 On Thu, Aug 12, 2010 at 08:52:22PM +0300, Felipe Contreras wrote: > On Thu, Aug 12, 2010 at 7:19 PM, Paul E. McKenney > <paulmck(a)linux.vnet.ibm.com> wrote: [ . . . ] (For now, anyway. I might respond to the rest later.) > >> 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. > > > > I do? �Really??? �Exactly what did I say to give you that impression? > > Here's your point 4 again: > > > >> > 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. > > Remove "but worse energy efficiency" and I think that point would be > correct, Now this is much more like it!!! Thank you!!! You are quite correct, my last sentence does in fact assume that suspend will always have lower power consumption than does the deepest idle state. This of course sentence must be fixed. How about the following, which makes this assumption explicit, and adds words ("often", "might") that indicate that one's mileage might vary? 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 often has shorter average wakeup latencies, but on systems where suspend can use deeper sleep states than can idle, idle might have worse energy efficiency. > albeit it's not really an argument in favor of opportunistic > suspend. It never was intended to be an argument of any kind. It was instead supposed to help clarify the difference between idle and suspend, in response to people stating that there is no difference between suspend and idle. If my mistake in the wording of the last sentence made you think otherwise, please accept my apologies. [ . . . ] (For now, anyway. I might respond to the rest later.) 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: Felipe Contreras on 12 Aug 2010 15:10 On Thu, Aug 12, 2010 at 9:21 PM, Ted Ts'o <tytso(a)mit.edu> wrote: > On Thu, Aug 12, 2010 at 07:46:03PM +0300, Felipe Contreras wrote: > >> All the Android community had to do is push the drivers *without* >> suspend blockers, then the Android kernel wouldn't be so different and >> thus wouldn't be considered a fork. AFAIU the kernel side wakelocks >> are already in the kernel, so there's no excuse not to merge the >> drivers. > > What's there is not good enough, because it's missing the statistics > and reporting so that badly behaved kernel and userspace drivers that > take wakelocks can be found. You don't need to have all the code merged in, hell, you only needed wakelock stubs. You should take the point of view of the community as a whole, and forget about Android for a second; the important thing is to bring the code-bases closer, and that means merging the drivers. For that, you don't need anything extra. -- 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 12 Aug 2010 15:10 Hi Brian, On Thu, Aug 12, 2010 at 8:33 PM, Brian Swetland <swetland(a)google.com> wrote: > On Thu, Aug 12, 2010 at 9:57 AM, Felipe Contreras > <felipe.contreras(a)gmail.com> wrote: >> >> Correct, but still a considerable amount of changes would need to be >> done, which _nobody_ has expressed any intention to do. >> >> Besides, IMO a good mobile platform would share as much as possible >> with desktop software. Say, the improvements Nokia has endorsed on the >> Telepathy IM framework can only help the people already using it on >> the desktop. >> >> However, personally, if I ever have to do './configure >> --enable-suspend-blockers', I would think that something that just >> doesn't belong has creped by to user-space. I don't see why there >> should something particularly different between mobile phones and >> laptops, and I think this has been already expressed over, and over. > > So, because you feel that phones should be little laptops you oppose > providing (optional!) support for environments that take a different > view to that? Look. I'll share with you a little experience. For years I've been working on a piece of software to access Microsoft's WLM IM service on linux. I have high quality standards for my software, so I optimized algorithms and bandwith, I used valgrind to find memory leaks, OProfile for performance bottlenecks, and so on. All this on a laptop. When I ported this code to the N900 it just worked, not more-or-less; perfectly. I could stay online the whole day without the battery running out, and I didn't have to make *any* change. Then at some point people started complaining about battery usage, but lo and behold, on the desktop people started reporting too much bandwith/cpu usage as well. I tried on my laptop, and was able to reproduce, and fix (bug related to daylight savings time). For years people have been trying to unify certain KDE/GNOME code, and freedesktop.org was born. Now the same technologies are used by Nokia on Maemo, and now MeeGo (DBus, Telepathy, GStreamer, tracker, etc.), so the optimizations done for mobile benefit everyone; desktop power usage also improves. So, yeah, I think the fact that my laptop and phone share the same software is great, and that improvements in one benefit the other. > I think that we're still a ways away from a world where we can treat > mobile devices the same as laptops and get reasonable user > experiences. Why do you keep ignoring the N900? It has a lot of components that come directly from the linux ecosystem and people are having more than reasonable experiences (some are ecstatic). > I think it's unfortunate if the attitude here is "wait > and someday it won't matter", especially because I'm skeptical that > we're likely to hit that "someday" any time soon. Nobody is waiting for anything. There's hard work all over the place to improve power usage. If you think suspend blockers are useful for you, great, use them. I just don't see why they should be merged if nobody is going to use them but you. But maybe you are right, and maybe dynamic PM alone never reaches the same levers of performance, then people would ask for it to be merged, and it will. No biggie. In the meantime, it would be wise to remember that this is not Nokia/Intel vs Google. Nokia has invested a great deal in dynamic PM, and those changes have benefited Android products directly (I even remember somebody from Google directly thanking Nokia for that), and that will continue. So we are on the same team. And finally, if they don't get merged, I hope you don't see that as a loss. At the very least I think you got a lot of review comments from the most qualified experts in the world _free of charge_, and as a result the code should be more robust. 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: Brian Swetland on 12 Aug 2010 15:20
On Thu, Aug 12, 2010 at 12:05 PM, Felipe Contreras <felipe.contreras(a)gmail.com> wrote: > On Thu, Aug 12, 2010 at 9:21 PM, Ted Ts'o <tytso(a)mit.edu> wrote: >> On Thu, Aug 12, 2010 at 07:46:03PM +0300, Felipe Contreras wrote: >> >>> All the Android community had to do is push the drivers *without* >>> suspend blockers, then the Android kernel wouldn't be so different and >>> thus wouldn't be considered a fork. AFAIU the kernel side wakelocks >>> are already in the kernel, so there's no excuse not to merge the >>> drivers. >> >> What's there is not good enough, because it's missing the statistics >> and reporting so that badly behaved kernel and userspace drivers that >> take wakelocks can be found. > > You don't need to have all the code merged in, hell, you only needed > wakelock stubs. > > You should take the point of view of the community as a whole, and > forget about Android for a second; the important thing is to bring the > code-bases closer, and that means merging the drivers. For that, you > don't need anything extra. Stubs would be 100% fine by me. Previous discussion has indicated that they are not acceptable without some firm timeline for removal. I don't think I can commit to a firm removal timeline while we're still making almost no forward progress. If we don't have to commit to yanking them back out in two releases or whatnot, then awesome, let's drop some stubs in and off we go, worrying about merging drivers that everyone agrees they want. Question though -- has every feature ever added to the kernel been a feature that there's pre-existing usage of? Seems like a chicken and egg problem. Also, some people seem to think there's value in being able to build kernels "out of the box" that work with the Android userspace -- given that there are a few devices out there that have that userspace on 'em. 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/ |