Attempted summary of suspend-blockers LKML thread, take three
in [Kernel]
|
From: Felipe Contreras on 12 Aug 2010 15:40 On Thu, Aug 12, 2010 at 8:43 PM, Paul E. McKenney <paulmck(a)linux.vnet.ibm.com> wrote: > On Thu, Aug 12, 2010 at 02:11:22PM +0300, Felipe Contreras wrote: >> So far, nobody has refuted these: >> 1) opportunistic suspend needs a good behaved user-space to work properly > > As does dynamic power management. Thus remains unrefuted. >> 2) if suspend blockers are enabled in a system, *all* user-space must >> implement them to work correctly > > Really? From what I can see, only PM-driving applications need to use > suspend blockers. "PM-driving applications" is a new invention, so how do you know if an application belongs to this category or not? Some application might be non-PM-driving most of the time, but suddenly become PM-driving. Well, you have to analyze *all* of them. Think about this... is bash a PM driving application? No, but what if you run: 'sleep 3600 && alarm.sh'. Perhaps I should rewrite that as: 2) if suspend blockers are enabled in the system; *all* user-space is affected >> 3) implementing suspend blockers in user-space is not a straight-forward task > > Fortunately, experience thus far has shown that only a small fraction of > applications need to use suspend blockers. Wrong. We don't have any experience on that at all on typical linux ecosystems (remember that Android's user-space is very special). >> So, as the length of this thread has shown, the benefits of >> opportunistic suspend are *dubious* at best, and more likely not worth >> the changes needed in user-space which eventually will get pretty >> close to what suspend blockers can achieve even in ideal circumstances >> by just doing dynamic PM. > > The length of this thread (and the ones preceding it) is mostly due to > people talking past each other. Perhaps half of the thread, or even one quarter of the thread can be attributed to that, but still the rest I think it's because people keep pushing in, and people keep pushing out. > For example, the Android folks seem to > believe that it is important that relatively unskilled people be able > to write simple apps, and that the system nevertheless be able to run > these apps in a relatively energy efficient manner. Your proposals do > not address this issue. This might be because you are not aware of > this desire, because you are not aware of the computing history that > argues in favor of this requirement, or because you simply don't like > this requirement. Whatever the reason, until you face this requirement > head on, either addressing it or proving that it need not be addressed, > you will continue to be talking past the Android folks. This "requirement" is specific to Android's user-space, isn't it? 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. -- 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:50 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? If we're an undesirable second-class citizen, why do people care that "android is forking the kernel"? I guess I don't understand, 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/
From: Jesse Barnes on 12 Aug 2010 16:00 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? :) -- Jesse Barnes, Intel Open Source Technology Center -- 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: Rafael J. Wysocki on 12 Aug 2010 23:40 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 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 -- 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: Arve Hjønnevåg on 13 Aug 2010 00:40
On Thu, Aug 12, 2010 at 8:28 PM, Rafael J. Wysocki <rjw(a)sisk.pl> 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. > Can you clarify this? Do you not believe using opportunistic suspend is the right approach, or do you not believe linking suspend blockers with opportunistic suspend 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. 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 needs. > �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 blockers these processes are allowed to use). > 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 Nexus One). > 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. > When we don't need these heuristics, this is just a burden. > 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). 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 need. >�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 > -- > 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/ > -- Arve Hj�nnev�g -- 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/ |