login
Search
That seems entirely reasonable, since opportunistic suspend is essentially a userspace facility. Its in-kernel component is extremely That isn't clear at all. Certainly they must be implemented correctly in some parts of userspace. But other parts can simply be denied Perhaps so. Lots of things in userspace aren't straight-forward -- GUIs, for example. So what? That's not a proof they shouldn't be Agreed. It is platform dependent. The Google people seem to believe You're ignoring the fact that Android has _already_ made the necessary userspace changes. Now you're going to ask them to change back, offering as motivation the loss of a real (albeit "dubious") power-saving advantage? Why should they accept your offer? Alan Stern --
Yes, but all user-space needs to be considered. There certainly will be cases when people think a certain package doesn't need them, but it turns out they did. Firefox? Nah... oh, wait a second, I want my downloads to finish. Do you think there will be any linux desktop Certainly not, but it means when measuring against plain dynamic PM, Yes, and Nokia/Intel people believe they are close on their platforms. Android people have been selling the idea that suspend blockers are not only for Android, but other platforms can benefit from them too. I am arguing in that context. Hopefully you agree that that claim is dubious at best. Now, switching to Android... I'm sure if Android guys say their user-space is far from the dynamic PM sweet-spot, then that's the case. Surely, at some point they will reach it, so that they can minimize power usage even when the device is actively used (it has been explained that opportunistic suspend is not activated when screen is on), maybe it will take one year, maybe two. Will they keep opportunistic suspend around for those marginal gains? Maybe. The question is why are we adding a user-space API that: 1) no user-space beside Android has expresses interest in implementing 2) is dubious whether the benefits are worth the pain for non-Android user-space 3) will become less and less attractive as dynamic PM gets closer to the sweet-spot, and then surpass it 4) Android can keep in a separate tree until it's clear in the linux community that it's useful (if it ever happens) -- Felipe Contreras --
So, Felipe, Do you believe you speak for all of LKML? Are you willing to tell ZDNet and the Slashdot fanboys that it's OK for Suspend blockers to live in a separate tree, and it's not a case of OMG! Google is forking the kernel? If you could speak out a passionately on those forums as you have here, that would be great. - Ted --
No. I'm speaking for myself, and that includes a lot of what people on 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. Then people would stop blaming Google for forking the kernel. Nobody from the "media" cares about suspend blockers; they are a small patch which cannot be considered a fork, more like a hack, like many other platforms have. -- Felipe Contreras --
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
--
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 --
On Thu, Aug 12, 2010 at 12:05 PM, Felipe Contreras 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 --
On Thu, 12 Aug 2010 12:19:34 -0700 We generally try to merge new features like this along with code that uses said feature, but there are always exceptions. We've merged code one release or more before the new code gets used for example, which is fine IMO. What we don't want to see is some new drop of code added and abandoned, but you already knew that. At any rate, if Felipe is the only one arguing against including suspend blockers in the kernel, you're probably in good shape. Based on my (rather cursory I admit) evaluation of this thread, it seems like reasonable people agree that there's a place for a suspend blocker like API in the kernel, and that dynamic power management is also highly desirable. So where's the git pull request already? :) -- Jesse Barnes, Intel Open Source Technology Center --
In fact my patch going in that direction has been merged already and that code will likely be extended to cover some needs and cases I didn't have in mind when I was preparing it. However, having discussed the whole issue for many times and reconsidered it thoroughly, I think that it's inappropriate to identify the suspend blockers (or wakelocks) framework with the opportunistic suspend feature as proposed in the original submission of the "suspend blockers" patchset. IMO they really are not the same thing and while the suspend blockers framework is used by Android to implement opportunistic suspend, I don't really believe this is the right approach. We really need something similar to suspend blockers to avoid races between a suspend process and wakeup events, but it isn't necessary to provide user space with an interface allowing it to use these things directly. Such an interface is only necessary in the specific implementation in which the system is suspended as soon as the number of "active" suspend blockers goes down to zero. Arguably, though, this isn't the only possible way to implement a mechanism allowing the system to be suspended automatically when it appears to be inactive. Namely, one can use a user space power manager for this purpose and actually the OLPC project has been doing that successfully for some time, which clearly demonstrates that the Android approach to this problem is not the only one possible. Moreover, the kernel's system suspend (or hibernate for that matter) code has not been designed to be started from within the kernel. It's been designed to allow a privileged user space process to request the kernel to put the system into a sleep state at any given time regardless of what the other user space processes are doing. While it can be started from within the kernel, this isn't particularly nice and, in the Android case, starting it from within the kernel requires permission from multiple user space processes (given by not taking suspend ...
Can you clarify this? Do you not believe using opportunistic suspend is the right approach, or do you not believe linking suspend blockers I don't think what you are saying here is correct. When you decide to suspend has no impact on whether a user space interface to block suspend is needed. The last suspend blocker patchset had this interface as a separate patch and the reasons for providing it have not changed with your interface. Android need the user space interface because low level services that handle wakeup events are started before the user space power manager. The other reason to have this interface in the mainline kernel is to provide a safe way to handle wakeup events on linux regardless of which user space power manager is used on the system. For instance some devices have a user space battery monitor, and there would be no need for this code to be android specific if the kernel provided all the functionality it Why is starting suspend from within the kernel not nice? Personally I think reentering suspend from within the kernel is nicer than being forced to wake up a user space thread for events that are fully handled within the kernel (for instance the battery monitor on the There is no absolute need to start the suspend process from within the kernel, but it makes the user space code much simpler for what we -- Arve Hjønnevåg --
Well, the problem is, with your /dev/suspend_blocker interface, multiple user space processes are supposed to decide whether or not system suspend should be started and in general there don't seem to be any particularly good criteria for choosing these applications, in general. So, application writers may be tempted to use this interface in all programs and then the decision whether or not to allow these programs to affect system power management will be delegated to users. In turn, the users may not be technically qualified to make such a decision. Also the fact that the same mechanism is used for handling wakeup events detected by the kernel and allowing user space programs to grant permission to For basically the same reason why the kernel generally doesn't use sys_open() The word 'arbitrary' means in particular that you can implement a mechanism equivalent to the /dev/suspend_blocker entirely in user space. Someone else, though, can use a different approach. By adding the /dev/suspend_blocker interface to the mainline kernel we would mandate that Linux applications use it on all platforms. Consequently, application writers would have the right to expect that all platforms would be I'm entirely aware of that. Still, I think user space is the right place to initiate system suspend. Thanks, Rafael --
On Fri, 13 Aug 2010 17:07:02 +0200 For what it's worth - I completely agree. Clearly there is no a lot of unanimity on this, and so lots of room to experiment with different approaches. It's best if we leave as much as possible of that experimentation in user-space - just have the kernel do what cannot be done elsewhere. NeilBrown --
For events that are fully handled within the kernel -- like battery monitor on Zaurus/spitz -- doing wakeup all the way to the userspace is not neccessary. But that's implementenation detail with no impact on user/kernel interface, and we are doing that today. (Or were doing that few releases ago; charging is broken on spitz just now). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --
rafael j. wysocki wrote: > On Thursday, August 12, 2010, Jesse Barnes wrote: > > On Thu, 12 Aug 2010 12:19:34 -0700 > > Brian Swetland <swetland@google.com> wrote: > > > 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. > > > > We generally try to merge new features like this along with code that > > uses said feature, but there are always exceptions. We've merged code > > one release or more before the new code gets used for example, which is > > fine IMO. What we don't want to see is some new drop of code added and > > abandoned, but you already knew that. > > > > At any rate, if Felipe is the only one arguing against including > > suspend blockers in the kernel, you're probably in good shape. Based > > on my (rather cursory I admit) evaluation of this thread, it seems like > > reasonable people agree that there's a place for a suspend blocker like > > API in the kernel, and that dynamic power management is also highly > > desirable. So where's the git pull request already? :) > > In fact my patch going in that direction has been merged already and that > code will likely be extended to cover some needs and cases I didn't have in > mind when I was preparing it. > > However, having discussed the whole issue for many times and reconsidered it > thoroughly, I think that it's inappropriate to identify the suspend blockers > (or wakelocks) framework with the opportunistic suspend feature as proposed in > the original submission of the "suspend blockers" patchset. IMO they really > are not the same thing and while the suspend blockers framework is used by > Android to implement opportunistic suspend, ...
On Fri, 13 Aug 2010 05:28:21 +0200 Yeah, I like what you've done with dynamic power management, really good stuff (the approach is very similar to the one I used for vblank interrupt management in the drm layer). Ted's point about providing the user with a way of knowing which apps are blocking things is a good one though, and doesn't seem too hard to add. It might even be possible to do it largely with scripts wrapping Yes, I see your point. But I actually think this is a fairly minor distinction. In one case, a privileged app decides when to suspend the system, in the other case, one or more of several privileged apps decide when a suspend should not be allowed to occur. It's just a matter of where you want to put the code and where you want the complexity. In general, we try to keep such complexity out of the kernel, but not always; there are compelling cases for putting complexity in the kernel to provide uniformity and flexibility (e.g. application state save/restore vs. system-wide checkpoints, the former preserves the "if it can be done outside the kernel, it should be", while the latter provides much greater flexibility and avoids the need to port applications to potentially incompatible or unportable state saves/restore libraries). -- Jesse Barnes, Intel Open Source Technology Center --
Well, that used to be my opinion before the whole discussion started, but now I think there's more to it. First off, we need the "forced" suspend, initiated by writing to /sys/power/state, to work regardless of the "opportunistic" one. Now, the races between wakeup events and suspend process are also a problem for the "forced" suspend mechanism, so the fix should not be specific to "opportunistic" suspend. One could argue that that can be fixed by using wakelocks as proposed by the Android developers, but this is not the case, because there's no way to disinguish wakelocks taken by applications (that we don't want the "forced" suspend to react to) from the wakelocks taken by the kernel (that are strictly related to "real" wakeup events). Second, system suspend is really an intrusive operation that does violent things to many kernel subsystems (it freezes tasks, it puts the mm subsystem into a degraded mode, it forcibly offlines non-boot CPUs and so on). If that is to be started from the kernel, the kernel thread starting it should really ask all of these subsystems if they are OK with whatever it wants to do and the answer would always be "no" in the majority of cases. The very purpose of that design is to allow a user to suspend the system whenever he wants and not to do that when there's an opportunity to power down things because they appear to be inactive (that may or may not be one of the "whenever the user wants" situations, but really the user should be able to specify the conditions). The powering down of things by the kernel when there's an opportunity should really be done in a more intelligent way (simply becasue the kernel is potentially able to do that more intelligently). Finally, in the kernel-driven opportunistic suspend scenario (using wakelocks) it is not particularly clear which applications should be given the priviledge to participate in the suspend blocking mechanism. I don't think there are any criteria which can be universally used for selecting ...
If Android guys provided a bare minimal Debian system with suspend blockers that people can take a look at and try, I think that would be I certainly have been the more vocal recently, but if that's confusing you, I can shut up and let others do the argumentation. I remember at least Alan Cox, Alan Stern, Thomas Gleixner, Kevin Hilman, Felipe Balbi, Tony Lindgren, and Igor Stopa against them. -- Felipe Contreras --
Yes, that would certainly help. I guess this is the major point -- as suspend blockers seem very suitable for android, they don't seem suitable for anyone else... -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --
Well firstly you want limits so SELinux says "No" (or rlimit or similar) and secondly you want sysfs views. This is like file permissions - its not hard --
Ted, what is going on here? Are you suggesting people disagreeing with Google patches suddenly have to do advocacy for Google? And yes, for the record Felipe speaks for me pretty well. Normal path of merging stuff to the kernel is "Google develops it, then modifies it to address the review comments, then it is merged, then it is deployed". Unfortunately what Google did here is: "Google develops it behind the closed door, then deploys it. When asked for changes, Google expects someone else to create system compatible with their existing solution, or else their patches being merged." Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --
Not that I´m as "valuable" as the others quoted above: I have the same That basically sums it up as far as I see. Bernd -- Bernd Petrovitsch Email : bernd@petrovitsch.priv.at LUGA : http://www.luga.at --
On Sat, 14 Aug 2010 09:50:00 +0200 Pavel, you should know better than this. You've been working on Linux long enough to know that development doesn't happen this way. It's far more common (and prudent, business-wise) for companies to develop changes against upstream Linux, ship them, and then try to get them or something like them integrated upstream. This often works fine, but big problems arise when either the company in question doesn't bother to ever push upstream (Linux loses out on support for a given feature or hardware) or ships changes that have very little Although it would have been nice for Google to work more directly with upstream on their suspend blockers for Android, I don't think they could have made their product development cycle a slave to the politics of upstream development. Fortunately in this case the problem doesn't seem to be fatal. We've already established that the userland API portion of suspend blockers could be implemented in userspace with a bit more work, given that the kernel problems with suspend/resume and events are addressed. Hopefully Google is already developing a prototype userspace implementation to make sure it's workable; being able to build stock upstream kernels for my Droid and its Android userspace sure would be nice. -- Jesse Barnes, Intel Open Source Technology Center --
You know, you don't have to wait for the Android engineers to do this work. You (or others who want to be able to use stock upstream kernel with Android devices) could just as easily try to do the "bit more work" yourselves --- that is, do the open souce thing and scratch one's own itch. After all, Rafael is saying he's refusing to accept patches (or implement) in-kernel oppunsitic suspend for upstream unless it's proven to him that a userspace implementation isn't sufficient. It might be just as fair for the Android userspace upstream to refuse to accept (or engineer) userspace changes unless it is proven that the userspace version of opporunistic suspend is just as good as the in-kernel version which is successfully been deployed in millions and millions of shipping units today... Speaking personally, it's not clear to me how waking up a userspace suspend daemon and waiting for it to get scheduled will result in better power savings than simply handling it in the kernel, but as soon as someone is willing to do the work, we can find out for sure who is right. - Ted --
On Mon, 16 Aug 2010 20:20:32 -0400 Sure, I could. And the Google guys could put together a whole Debian distro with suspend blockers sprinkled throughout various apps. But for my part, I can't justify that kind of work at the moment. Of course I'd be happy if someone could and did do the work, it would be a useful exercise and potentially allow Android to work well on stock Yeah it would add some overhead, since suspend blocker calls would use IPC to a userspace daemon, which would also be responsible for (periodically?) waking up to see if the system ought to be suspended... I agree coding it up would be a useful exercise. -- Jesse Barnes, Intel Open Source Technology Center --
On Mon, 16 Aug 2010 20:20:32 -0400 Reminds me of the one of the first questions asked in a murder investigation (or so they say on TV) Cui Bono?? Who benefits? Does Android benefit more by being able to use a standard kernel, or does Linux benefit more by being able to run Android without modification. Currently it seems that only the lawyers^Wpeople who like arguing on lkml are gaining anything. Maybe this is the first real fork of Linux - google might be rich enough to I'm surprised at this comment Ted! Power saving is not the single supreme goal, yet you make it sound like it is. It should be no surprise to anyone if the most maintainable solution uses a little more power than the most highly optimised solution. I think most of us would still prefer the more maintainable solution. However, if google sees a market opportunity for the minor optimisation of suspend-from-kernel rather than suspend-from-user-space, then it would seem they are welcome to it. NeilBrown --
Define "real fork"? Both SuSE and Red Hat have carried patches, in some cases for years, forward porting them to newer kernels. Does that make them forks? SuSE has made changes to e2fsprogs, and carried those patches for years and years, and even added options to command-line programs which SLES's init scripts are dependent on --- and this was done without even consulting me first. Yet you don't see me calling out SLES for "forking" e2fsprogs and how it "got away" with it. Can we please cut out this whole forking nonsense? I've been told that it's only something Slashdot kiddies and ZDNet media types looking for advertising impressions. Yet you're a kernel programmer, and one who works for a distribution, and you've made this same claim; I think part of the problem here is what's considered "acceptable" to one set of developers may not be considered "acceptable" to another set. As I've said many times before, what makes sense for a cell phone battery and highly power-optimized hardware may not make sense for a devices with 6-cell laptop battery. And I think it's still to be seen whether or not suspend-from-userspace really is as minor as people think it is, and what compromises might have to be made in how app programs are forced to develop their applications, etc. - Ted --
My initial impression was also that power savings was Android's single supreme goal, but a careful reading of this thread and the ones preceding it taught me otherwise. Please see below for my current understanding of what they are trying to accomplish. As always, feedback is welcome! Thanx, Paul ------------------------------------------------------------------------ Subject: Attempted summary of suspend-blockers LKML thread, epilogue 1 Final report from this particular angel-free zone for the time being... This is the third^Wfourth and final version of my Android requirements list (last version available at http://lkml.org/lkml/2010/8/6/581). Again, this email is an attempt to present the Android guys' requirements, based on my interpretation of LKML discussions. Thank you to everyone who took part. Please note that I am not proposing a solution that meets these requirements, nor am I attempting to judge the various proposed solutions. In fact, I am not trying to judge whether the requirements are optimal, or even whether or not they make sense at all. My only goal at the moment is to improve our collective understanding of what the Android folks' requirements are. That said, I do discuss example mechanisms where needed to clarify the meaning of the requirements. This should not be interpreted as a preference for any given example mechanism. Thanx, Paul ------------------------------------------------------------------------ CONTENTS o DEFINITIONS o CATEGORIES OF APPLICATION BEHAVIOR o REQUIREMENTS o NICE-TO-HAVES o APPARENT NON-REQUIREMENTS o SUGGESTED USAGE o POWER-OPTIMIZED APPLICATIONS o OTHER EXAMPLE APPLICATIONS o ACKNOWLEDGMENTS DEFINITIONS These have been updated based on LKML and linux-pm discussions. The names are probably still sub-optimal, but incremental progress is nevertheless a very good thing. o "Ill-behaved application" AKA "untrusted application" AKA "crappy application". The Android guys seem to be ...
Well, I know that world is not always ideal, but it still surprised me "Slave of upstream politics" would be going all the way; seeing the patches before there were million devices out there would also help a You are an optimist. Yes, I also hope it will work out fine, but... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --