Attempted summary of suspend-blockers LKML thread, take three
in [Kernel]
|
From: Paul Fox on 13 Aug 2010 01:00 rafael j. wysocki wrote: > On Thursday, August 12, 2010, Jesse Barnes wrote: > > On Thu, 12 Aug 2010 12:19:34 -0700 > > Brian Swetland <swetland(a)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, 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 hey! how did we get dragged into this? :-) it's true that OLPC has a user-level power management daemon that implements our suspend policy. it uses various metrics and heuristics (i've been told that's latin for "hacks") to decide when the system is "idle enough" to suspend, along with whether to leave our independent display running or not, and whether to leave the wlan active, etc. it does a reasonable job for us for now, but being intimately familiar with the chewing gum and string that hold it together, i don't want anyone to think we've solved a Big Problem. i do think that there's a place for a flexible user-level policy engine, no matter how the suspend blockers vs. whatever-else issue plays out. i guess i assumed that that was a given -- does android not have such a policy manager? surely there's more to it than just "last one out, turn out the lights"? (i should also mention that we definitely see the suspend vs. wakeup events race issue, and are looking forward to ways to clean that up.) paul > 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 blockers these processes are allowed to use). > > Since, quite clearly, user space input is necessary to make the decision > whether or not to suspend the system, I think it is more appropriate to allow > user space to start the entire operation and provide the kernel with a means > to abort it in the case of a wakeup event. Then, user space will be able to > use arbitrary heuristics in deciding whether or not to suspend the system, > possibly taking some kernel's input into account. > > I'm not against the very idea of automatic system suspend, which IMO is a > legitimate and reasonable thing to do in many usage scenarios, but I don't > think that the kernel is the right place to start a suspend process. For this > reason I'm not going to take any code trying to start a suspend process from > within the kernel, regardless of that code's purpose, unless somebody makes a > really convincing case for that to me (basically proving the need for such a > solution). That said I'm willing to accept patches adding or improving code > that will help us to avoid races between system suspend, initiated by user > space, and wakeup events detected by the kernel. > > I hope that makes things clear. > > Thanks, > Rafael > _______________________________________________ > linux-pm mailing list > linux-pm(a)lists.linux-foundation.org > https://lists.linux-foundation.org/mailman/listinfo/linux-pm =--------------------- paul fox, pgf(a)laptop.org -- 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: Alan Cox on 13 Aug 2010 06:40 > Why do people care that "android is forking the kernel"? A lot of us don't. That's what the GPL is about. It's a big pain if you start splitting it off into two entire things long term - because your maintenance grows harder exponentially but parallel forks are common - SuSE and RHEL Enterprise type editions are forks for example. As far as I can tell it all comes from one or two people with a big PR presence and almost no code in the kernel saying silly things years ago which the IT press see as a good way to create a 'we need a column, bash someone' story. "What the junk press think" is a common but broken way to run national policy in some countries, and its just as broken for the kernel. Alan -- 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: Alan Cox on 13 Aug 2010 06:50 > 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 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 -- 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: Alan Cox on 13 Aug 2010 07:00 > > Think in terms of an ARM laptop. What good is opportunistic suspend if > > it's not going to help when the laptop is being used? > > For when the laptop is not being used, presumably. Or in time between keystrokes for most of the platform (backlight excepted). The Intel MID x86 devices are at the point that suspend/resume time on x86 is being hurt by the kernel rewriting smp alternatives as we go from 2 processors live to 1 and back. Alan -- 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 13 Aug 2010 07:00
On Thu, Aug 12, 2010 at 10:48 PM, Brian Swetland <swetland(a)google.com> wrote: > On Thu, Aug 12, 2010 at 12:34 PM, Felipe Contreras > <felipe.contreras(a)gmail.com> wrote: >> >> Not Ubuntu, not Fedora, not MeeGo, not anyone with a typical >> user-space seems to be having this problem. I can argue to you that >> this problem can be solved in easier ways, but instead I will argue >> that perhaps we should wait for somebody besides Android to complain >> about it before providing a "solution". Because after all, what good >> is a "solution" provided by the kernel, if the user-space is not going >> to use it, ever. > > I'm curious, when does Android count as a user of the kernel? I > gather that volume of sales or users doesn't count. Do we have to > include some percentage of "desktop" Linux? You are *one* user of the kernel. Let's suppose Android wasn't using suspend-blockers, and there was another equally successful linux mobile platform, Foobingo, and they were using them, and they were the only ones interested on implementing them. What does that change? Nothing. They still need to convince the community that what they are proposing to be merged is actually useful, and somebody will use it. If not, they can just keep the patch for themselves until they do. I don't see the big deal. > If we're an undesirable second-class citizen, why do people care that > "android is forking the kernel"? Nobody has expressed anything remotely like that (that you are a second-class citizen). Why makes you think so? Lots of people get patches denied. Like Nokia's u_char driver, which is *way* less controversial than this one. -- 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/ |