Attempted summary of suspend-blockers LKML thread, take three
in [Kernel]
|
From: Felipe Contreras on 13 Aug 2010 07:10 On Thu, Aug 12, 2010 at 10:57 PM, Jesse Barnes <jbarnes(a)virtuousgeek.org> 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. 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 a good proof of concept. And a bare minimum to get the patches merged. > 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? :) 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 -- 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 13 Aug 2010 10:50 On Fri, Aug 13, 2010 at 01:58:12PM +0300, Felipe Contreras wrote: > 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. So the current users of the Linux kernel are the following? o GNU/Linux o Android Do any other distributions or devices with unusual user-space layouts qualify? Thanx, Paul > > 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/
From: Rafael J. Wysocki on 13 Aug 2010 11:10 On Friday, August 13, 2010, Arve Hj�nnev�g wrote: > 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? The latter. That should be clear from the remaining part of my message. > > 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. 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 suspend the system is somewhat confusing. > > 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). For basically the same reason why the kernel generally doesn't use sys_open() for opening files. It is an interface provided for user space. > > 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. 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 using Android-alike opportunistic suspend, which may or may not be the case. > > 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. I'm entirely aware of that. Still, I think user space is the right place to initiate system suspend. 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: Paul E. McKenney on 13 Aug 2010 11:20 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: > > On Thu, Aug 12, 2010 at 03:17:29AM +0300, Felipe Contreras wrote: > >> Anyway, Alan was picturing a hypothetical point in time when x86 can > >> suspend/resume as fast as ARM, and thus the question of whether or not > >> to enable suspend-blockers in a system that runs openoffice becomes > >> relevant. If applications have been fixed by that time to not wake the > >> system unnecessarily, as many of them have already been tanks to tools > >> like powertop, then suspend-blockers would not make that much of a > >> difference, therefore the effort required to implement > >> suspend-blockers properly on all applications in the system, including > >> openoffice might not be worth the gain. > > > > One more time, this time with feeling. �;-) > > > > � � � �Only PM-driving applications need concern themselves with suspend > > � � � �blockers, and experience thus far indicates that PM-driving > > � � � �applications are a very small fraction of the total. > > There's no experience on this. Have you tried to run a small debian > system with suspend blockers enabled? I can image at least all cron > daemons need modifications, probably dbus, links, lftp, wget, rsync > and a bunch of applications that download data too. I have not. I would be surprised if anyone else did that work unless suspend blockers were in mainline. I would be very happy to be proven wrong, of course! > It's easy to speculate one way or the other, but the fact of the > matter is that we don't really know how many changes are needed in > order to have a functional system that actually benefits from suspend > blockers. > > What we know is that if an application is not analyzed to see if it > needs suspend blockers, and implement them if needed, it might get > broken. That would be your speculation. Perhaps you are correct, but it seems more likely that some large sets applications can be considered as a group rather than one at a time. > >> > Apparently different people in this debate have different targets. > >> > >> I remember clearly Android people explaining that dynamic PM is > >> orthogonal to suspend-blockers; if a suspend is blocked, you still > >> want dynamic PM to reach the lower power state. Therefore the target > >> of not having unneeded runnable tasks is shared by Android folks. > > > > And I have not seen anyone argue that suspend blockers are a replacement > > for dynamic power management. > > That's exactly what I'm saying: they are orthogonal. OK, good to know! Please understand that your sentence "Therefore the target of not having unneeded runnable tasks is shared by Android folks" can be interpreted as meaning "the Android guys really don't need suspend blockers", which is how I interpreted it. > > In contrast, you are advocating dynamic power management to the exclusion > > of other mechanisms. > > * if dynamic PM was perfect, spend-blockers would *not* be not needed > * if suspend-blockers were perfect, dynamic *will* still be needed > > All I said in that sentence you are replying is that dynamic PM will > improve; it's a shared goal of everyone. That is certainly not the way I read the sentence I was replying to, but I will accept that this was what you were really trying to say. > >> IOW. Alan wasn't talking about idle vs suspend on the same device, he > >> was talking about opportunistic suspend vs dynamic PM. > > > > The most convincing comparisons will be of suspend vs. idle on the > > same device. �If multiple devices are involved, then the most convincing > > experiments would compare suspend vs. idle separately on each device. > > > > So, are you sure that you are correctly interpreting Alan's words? > > The point you are trying to highlight is to which events the system > reacts, that has nothing to do with dynamic PM vs opportunistic > suspend. Ahem. I -do- know what -I- was trying to say. ;-) > > Again, I am in no way arguing for suspend blockers to the exclusion of > > other approaches. �Heck, I am mostly just trying to get a clear statement > > of the problem. �In contrast, you do seem to be advocating for dynamic > > power management to the exclusion of other approaches. > > What you are doing is copy pasting a definition of what is > opportunistic suspend and making it pass as an advantage. No, I was copy pasting a definition of a difference between idle and suspend and making it pass as a difference between idle and suspend. > This particular point (3.) is not an advantage, over dynamic PM, it's > just a difference. Yep. I never claimed otherwise. > >> No, I think both (for opportunistic suspend and dynamic PM) are > >> completely reasonable. But think again; if you have the assumptions > >> met on both, then both work fine, if you don't meet them, then both > >> don't work correctly. > > > > That is true of any artifact, software or otherwise: if you don't meet the > > assumptions inherent in its design and construction, the artifact might > > fail. > > [...] > > >�There is > > a very real difference between those two tasks. > > I've cut most of your explanation. Indeed you have! But you should be safe in doing so, as most people probably won't bother to do the web search that would lead them to http://lkml.org/lkml/2010/8/12/198 and then search that page for the word "artifact". ;-) > If I understand correctly what you > are saying is that suspend blockers are harder to get wrong. I agree, > but my point against 4. remains the same: suspend-blockers don't > automatically get you more efficient power usage. I am glad you agree that suspend blockers might be harder to get wrong. As to point #4, you were correct that I badly worded the last sentence, which is now hopefully fixed to your satisfaction. > > So are you sure that dynamic power management will turn out to be > > the right tool for every job out there? �If so, on what grounds? > > I don't understand this question. Dynamic PM is needed regardless. We > are discussing your point 4 where you say suspend blockers inevitably > lead to more efficient power usage (I say not necessarily). But can dynamic power management do everything optimally? If not, some other approach may be needed in addition to dynamic power management. If you really are arguing that the Linux kernel should support no power-management mechanism other than dynamic power management, you should be prepared to justify that position. > >> 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, albeit it's not really an argument in favor of opportunistic > suspend. Fix put forward in earlier email. Again, thank you -- good catch!!! > >> > It seems to me that the same social-engineering approaches work in > >> > both cases. > >> > >> Yes, but if dynamic PM works as advertised, you don't need > >> opportunistic suspend. > > > > For dynamic power management to totally eliminate the need for something > > like suspend blockers, you are having to make some brave assumptions. > > Yes, dynamic power management is quite useful, but there is a big > > difference between something being useful and something doing everything > > for everyone. �You have not yet convinced me that dynamic power management > > will make it to the "doing everything for everyone" stage. > > As it has been explained before, there's a sweet-spot of idleness: > http://article.gmane.org/gmane.linux.kernel/995525 > http://article.gmane.org/gmane.linux.ports.arm.omap/37982 > > Do you agree that there's such a thing, and if so, do you agree that > the benefits of opportunistic suspend are much less once that point is > reached? I agree that there will be a sweet spot of idleness (though I would call it a "point of diminishing returns"), but only if all the applications are power-optimized. The advantage of opportunistic suspend is instead its tolerance of power-oblivious applications with minimal degradation of battery life. > >> >> If not, you'll see much worst energy efficiency. So in theory maybe, > >> >> but in practice you can't say that. > >> > > >> > Really? �What makes you say that? > >> > >> For starters an application might be holding the wakelock more than it > >> should, also, an application might miss a timer due to not having PM > >> permissions to hold the lock, and thus might need an expensive > >> initialization when it runs again. > > > > Just as an application might run continuously without blocking, which > > would defeat the dynamic power management scheme that have thus far been > > put forward. �And just as an application might miss a timer due to > > dynamic power management having decided that it didn't need that timer > > to fire at the desired time. > > You are making this discussion entropic, concentrate on what I said: > >>>> If not, you'll see much worst energy efficiency. So in theory maybe, > >>>> but in practice you can't say that. > > I just proved to you that in certain cases opportunistic suspend might > actually hurt. Thus you should accept my premise that you can't say > that in practice opportunistic suspend _always_ leads to better > results, because that's not the case. And in the paragraph above, I proved to you that relying solely on dynamic power management might actually hurt. And I am not trying to prove that opportunistic suspend always leads to better results -- that is a strawman that you set up. And yes, you might have been led to set up that strawman because I messed up the wording of one of the suspend-vs.-idle definitions. Of course, had you called out that sentence to start with, we would likely have spent much less time arguing generalities. ;-) > And in order to try to avoid going back to the same points: > 1) yes, there are advantages of opportunistic suspend Good, agreed. > 2) yes, there are cases where it works as it should Good, agreed. > 3) no, it's not a silver bullet that will inevitably improve power usage Agreed. This is no surprise, as there are very few silver bullets to be had in this field. Of course, dynamic power management is not a silver bullet, either. > 4) no, we can't say anything about what opportunistic suspend means in practice Here I disagree. The Android folks have used it for quite some time. We might not be able to apply their experience directly to other software stacks, but we should nevertheless be able to learn quite a bit from it. 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 13 Aug 2010 11:30
On Fri, Aug 13, 2010 at 6:14 PM, Paul E. McKenney <paulmck(a)linux.vnet.ibm.com> wrote: > On Thu, Aug 12, 2010 at 08:52:22PM +0300, Felipe Contreras wrote: >> 4) no, we can't say anything about what opportunistic suspend means in practice > > Here I disagree. The Android folks have used it for quite some time. > We might not be able to apply their experience directly to other software > stacks, but we should nevertheless be able to learn quite a bit from it. So when it comes to practice you are relying solely on what Android people say. If it's true that it's easy to spot the "PM-driving applications", then it shouldn't be hard for a guy from the Android team to assemble a basic typical system (X.org, dbus, etc.) with suspend-blockers in a couple of days. -- 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/ |