Attempted summary of suspend-blockers LKML thread, take three
in [Kernel]
|
From: Paul E. McKenney on 13 Aug 2010 11:30 On Fri, Aug 13, 2010 at 11:57:51AM +0100, Alan Cox wrote: > > > 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. Given that you are talking about going from 2 processors to 1 and back, I would guess that you are not actually talking about suspend/resume, which is a system-wide thing rather than a CPU-by-CPU thing. I am not sure whether you are using CPU hotplug or invoking SMP alternatives once all but one CPU is idle. Can't say that I can tell exactly what pit you are digging for me here. ;-) 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:50 On Fri, Aug 13, 2010 at 6:22 PM, Paul E. McKenney <paulmck(a)linux.vnet.ibm.com> wrote: > On Thu, Aug 12, 2010 at 10:34:47PM +0300, Felipe Contreras wrote: >> "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. > > A PM-driving application is one that exerts control over the system's > power state. In the case of Android, a PM-driving application is one > that is permitted to acquire suspend blockers. I already mentioned that a "PM-driving application" might not have suspend-blockers; because the user denied them, or because the developer forgot them. >> Think about this... is bash a PM driving application? No, but what if >> you run: 'sleep 3600 && alarm.sh'. > > That is an excellent example, as it applies equally to dynamic power > management. By how much are you allowed to delay the wakeup? Huh? Certainly not days, which if Android guys are right, might be how much the task will be delayed. >> Perhaps I should rewrite that as: >> 2) if suspend blockers are enabled in the system; *all* user-space is affected > > That is speculation on your part. Not really. Say you have 100 packages in your system, how do you know which ones would be PM-driving? Can you grep for something, or see if they open certain file? No, you have to analyze them one by one; they *all* are affected, although not all might require modifications. But assuming I'm wrong, that's precisely the reason why a practical exercise would help. >> This "requirement" is specific to Android's user-space, isn't it? > > That is your speculation. Which is why we need something practical. >> 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. > > At this point in the discussion, I am quite prepared to believe that you > will avoid using suspend blockers, and that you will further do everything > in your power to prevent anyone else from using suspend blockers. ;-) I'm not tying anybody's hands. How are people using real-time linux if it's not on mainline? Well, duuh, you apply the patches. If say Fedora was interested on it, they could apply the patches, and see for themselves. People do that all the time, with the mm tree, with Con Koliva's patches, etc. Once people are happy with the results, things get merged. Why should this be any different? -- 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: Jesse Barnes on 13 Aug 2010 12:30 On Fri, 13 Aug 2010 05:28:21 +0200 "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. 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 fuser and such. > 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). 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 -- 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 13:20
On Fri, Aug 13, 2010 at 06:28:27PM +0300, Felipe Contreras wrote: > 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. So when it comes to practice with suspend blockers, only the Android people have any experience, so theirs is the only experience with suspend blockers that there is to rely on. ;-) ;-) ;-) > 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. I am happy to let the Android guys determine the best use for their time. 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/ |