[PATCH 0/8] Suspend block api (version 8)
in [Kernel]
|
Prev: [ANN] Linux Security Summit 2010 - Announcement and CFP
Next: [PATCH 4/8] PM: suspend_block: Add debugfs file
From: Alan Stern on 28 May 2010 10:40 On Fri, 28 May 2010, Alan Cox wrote: > If I push the button we get an IRQ > We come out of power save > The app gets poked > The app may be unimportant but the IRQ means we have a new timeout of > some form to run down to idle > The app marks itself important > The app stays awake for 60 seconds rsyncing your email > The app marks itself unimportant > Time elapses > We return to suspend > > > If you are absolutely utterly paranoid about it you need the button > driver to mark the task it wakes back as important rather than rely on > time for response like everyone else. That specific bit is uggglly but > worst case its just a google private patch to a few drivers. I understand > why Android wants it. The narrower the gap between 'we are doing nothing, > sit in lowest CPU on state' and 'we are off' the better the battery life > and the more hittable the condition. That "private patch to a few drivers" is almost exactly what suspend blockers are. Given that much of this discussion has revolved around whether suspend blockers are accptable in the kernel, I don't think you should shrug them off quite so easily. Also, you have forgotten about the case where there is no app waiting to get poked: The app is busy doing something else unimportant We do into power save Push a button, generate an IRQ Come out of power save No app to poke * System goes back to sleep and eventually wakes up again The app finishes what it was doing The app sees there is a keystroke and marks itself important ... The * step is where trouble can occur. Alan Stern -- 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: Matthew Garrett on 28 May 2010 10:50 On Fri, May 28, 2010 at 07:29:27AM -0700, Brian Swetland wrote: > I need to think more about the cgroups approach, but I'm pretty sure > it still suffers from wakeup race situations, and due to the > complexity of userspace (at least ours), I suspect it would risk > livelock/deadlock/priority-inversion style issues due to interaction > between different processes in different groups. I think the cgroups approach works if you assume that applications that consume wakeup events can be trusted to otherwise be good citizens. Everything that has no direct interest in wakeup events (except the generic Android userspace) can be frozen, and you can use the scheduler to make everything else Just Work. That's a rather big if, but you've got a better idea of the state of the Android app base than I do. -- Matthew Garrett | mjg59(a)srcf.ucam.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 Stern on 28 May 2010 11:00 On Fri, 28 May 2010, Peter Zijlstra wrote: > On Thu, 2010-05-27 at 20:59 -0400, Alan Stern wrote: > > On Fri, 28 May 2010, Rafael J. Wysocki wrote: > > > > > > And the forced-suspend design relies on the fact that processes remain > > > > frozen throughout. If we leave some processes unfrozen and one of them > > > > somehow becomes runnable, that means we have to abort the forced > > > > suspend before the process is allowed to run. > > > > > > We could avoid that if drivers could block tasks, but there are questions to > > > answer. First off, how a driver is supposed to know when to block the task > > > using it and when to do its power management transparently for the task? > > > Second, how to intercept and block all possible interfaces that user space > > > can use to talk to drivers (how to intercept a task using mmapped device, for > > > example)? > > > > We talked about this a few years ago and decided it was not feasible. > > It would require substantial changes to every device driver. > > But what if its the _right_ thing to do? We make changes to every device > driver out there on a regular basis. Also, why won't an incremental > process work? Add the interface with a fallback for drivers that haven't > implemented it and implement it for those drivers its most urgent (like > those in use on an Android phone). There is no reasonable fallback. In fact, I seriously doubt that there's any way to carry this out at all, reasonable or not. For example, how do you handle the situation where a user task gets an error because it accessed an mmapped address belonging to a device that has been suspended? > Not doing the right thing simply because its a lot of work seems like a > fine way to let the kernel rot into an unmaintainable mess. Firstly, it's not at all clear that this _is_ the right thing. Secondly, when doing the right thing involves making invasive changes to half the .c files in the kernel, people might stop to think that it would add more bugs than it would solve problems. Alan Stern -- 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: Peter Zijlstra on 28 May 2010 11:10 On Fri, 2010-05-28 at 15:20 +0200, Peter Zijlstra wrote: > On Fri, 2010-05-28 at 14:02 +0100, Alan Cox wrote: > > On Fri, 28 May 2010 14:30:36 +0200 > > Peter Zijlstra <peterz(a)infradead.org> wrote: > > > > > On Fri, 2010-05-28 at 13:21 +0100, Alan Cox wrote: > > > > [Total kernel changes > > > > > > > > Ability to mark/unmark a scheduler control group as outside of > > > > some parts of idle consideration. Generically useful and > > > > localised. Group latency will do most jobs fine (Zygo is correct > > > > it can't solve his backup case elegantly I think) > > > > > > > > Test in the idling logic to distinguish the case and only needed > > > > for a single Android specific power module. Generically useful > > > > and localised] > > > > > > I really don't like this.. > > > > > > Why can't we go with the previously suggested: make bad apps block on > > > QoS resources or send SIGXCPU, SIGSTOP, SIGTERM and eventually SIGKILL > > > > Ok. Are you happy with the QoS being attached to a scheduler control > > group and the use of them to figure out what is what ? > > Up to a point, but explicitly not running runnable tasks complicates the > task model significantly, and interacts with fun stuff like bandwidth > inheritance and priority/deadline inheritance like things -- a subject > you really don't want to complicate further. > > We really want to do our utmost best to make applications block on > something without altering our task model. > > If applications keep running despite being told repeatedly to cease, I > think the SIGKILL option is a sane one (they got SIGXCPU, SIGSTOP and > SIGTERM before that) and got ample opportunity to block on something. > > Traditional cpu resource management treats the CPU as an ever > replenished resource, breaking that assumption (not running runnable > tasks) puts us on very shaky ground indeed. Also, I'm not quite sure why we would need cgroups to pull this off. It seems most of the problems the suspend-blockers are trying to solve are due to the fact of not running runnable tasks. Not running runnable tasks can be seen as assigning tasks 0 bandwidth. Which is a situation extremely prone to all things inversion. Such a situation would require bandwidth inheritance to function at all, so possibly we can see suspend-blockers as a misguided implementation of that. So lets look at the problem, we want to be frugal with power, this means that the system as a whole should strive to do nothing. And we want to enforce this as strict as possible. If we look at the windowing thing, lets call it X, X will inform its clients about the visibility of their window, any client trying to draw to its window when it has been informed about it not being visible is wasting energy and should be punished. (I really wish the actual X on my desktop would do more of that -- its utterly rediculous that firefox keeps animating banners and the like when nobody can possibly see them) Clearly when we turn the screen off, nothing is visible and all clients should cease to draw. How do we want to punish dis-obedient clients? Is blocking them sufficient? Do we want to maintain a shitlist of iffy clients? Note that the 'buggy' client doesn't function properly, if we block its main event loop doing this, it won't respond to other events -- but as argued, its a buggy app, hence its per definition unreliable and we don't care. Next comes the interesting problem of who gets to keep the screen lit, I think in the above case that is a pure userspace problem and doesn't need kernel intervention. Can we apply the same reasoning to other resources, filesystems, network? For both of them it seems the main governing body isn't this windowing system, but the kernel (although arguably you could fully do it in middle-ware, just like X is that). But in both cases I think we can work with a QoS system where we assign some service-level to each task, and a server-level (with inverse priority scales to the task level), and only provide service when task-level >= server-level. [server-level 0 would serve everybody, task-level 0 would only get service when everybody does] If we allow userspace to set server-levels, we need to ensure that whoever is allowed that is a well functioning program. We can do a similar thing for wakeups, aside from setting wakeup slack, we can also set a wakeup limit per task, but I'm not quite sure how that would work out. That needs more thought. But an application exceeding its wakeup limit would still need to be woken (not doing so leads to fun problems) but the event is clearly attributable and loggable. -- 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 28 May 2010 11:10
> I think the suggestion that has the closet fit with what we're trying > to accomplish is Ingo's (or perhaps Ingo's explanation of Alan's): > http://lkml.org/lkml/2010/5/28/106 where it's implemented as a > constraint of some sort. I think we ended up in the same place on our own. > Arve points out that qos constraint objects could work (but not if > specifically tied to apps): http://lkml.org/lkml/2010/5/28/120 though > he suggests that "latency" constraints don't represent this as well as > "state" constraints. With latency you have an "I don't give damn" latency in your model which we could describe as infinite or "manyana" perhaps. > Though if you look at it that way, then suspend_blockers become qos > constraint objects, but their implementation and usage remain pretty > much the same as we have now, which does not address Alan's concern > regarding code turning up in drivers, etc. I'm not sure how you can > solve this problem (avoiding races around entering/exiting the suspend > or suspend-like state) without having a means for drivers to prevent > entry to that state. I am much much less concerned about general expressions of constraint appearing in drivers. One of my early mails gave a list of other people/projects/problems that need them - from hard real time, to high speed serial on low end embedded to virtualisation. They fix a general problem in terms of a driver specific item. We end up making changes around the tree but we make everyone happy not just Android. Also we are isolating policy properly. The apps and drivers say "I have these needs", the power manager figures out how to meet them. Where it gets ugly is if you start trying to have drivers giving an app a guarantee which the app then magically has to know to dispose of. If you are prepared to exclude untrusted apps from perfectly reliable event reporting (ie from finger to application action) that doesn't seem to be a neccessity anyway. > livelock/deadlock/priority-inversion style issues due to interaction > between different processes in different groups. Priority inversion with the cgroup case is like synchronization effects with the suspend blockers - its a real ugly problem and one that is known to be hard to fix if you let it happen so I agree there. -- 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/ |