suspend blockers & Android integration
in [Kernel]
|
Prev: How do I ignore the changes made by CVS keyword substitution efficiently?
Next: [PATCH 1/2] x86: make save_stack_address() !CONFIG_FRAME_POINTER friendly
From: Arve Hjønnevåg on 7 Jun 2010 20:50 On Sun, Jun 6, 2010 at 7:43 AM, Matt Helsley <matthltc(a)us.ibm.com> wrote: > On Sun, Jun 06, 2010 at 12:36:21PM +0200, Thomas Gleixner wrote: >> On Sat, 5 Jun 2010, Arve Hj�nnev�g wrote: > > <snip> > >> > events like input event go though a single thread in our system >> > process, while other events like network packets (which are also >> > wakeup events) goes directly to the app. > > If you want to wake up cgroup-frozen tasks for these fds perhaps your > framework can fcnt(fd, F_SETOWN, <p[g]id>) to send SIGIO to a How does the framework get all the fds that are used by the apps for wakeup events? > userspace-suspend-blocker thread/process/process group. When IO comes in, the > suspend blocker is signalled which then unfreezes the cgroup of the frozen > untrusted task. SIGIO works on pipes, fifos, sockets, ttys, and ptys -- > many of which are precisely the kinds of things that would connect [trusted > and untrusted] apps. Notably absent (last I checked): inotify fds, signalfd, > timerfd, eventfd, filesystem fds and likely more. > > Incidentally, this is just to show that it's not impossible to implement > "wakeups" for cgroup-frozen tasks in userspace. > > Cheers, > � � � �-Matt Helsley > -- 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/
From: Arve Hjønnevåg on 7 Jun 2010 21:00 On Sun, Jun 6, 2010 at 5:01 PM, Alan Stern <stern(a)rowland.harvard.edu> wrote: > On Sun, 6 Jun 2010, Matthew Garrett wrote: > >> The difference between idle-based suspend and opportunistic suspend is >> that the former will continue to wake up for timers and will never be >> entered if something is using CPU, whereas the latter will be entered >> whenever no suspend blocks are held. The problem with opportunistic >> suspend is that you might make the decision to suspend simultaneusly >> with a wakeup event being received. Suspend blocks facilitate >> synchronisation between the kernel and userspace to ensure that all such >> events have been consumed and handld appropriately. > > Remember that suspend takes place in several phases, the first of which > is to freeze tasks. �The phases can be controlled individually by the > process carrying out a suspend, and there's nothing to prevent you from > stopping after the freezer phase. �Devices won't get powered down, but > Android uses aggressive runtime power management for its devices > anyway. > > If you do this then the synchronization can be carried out entirely > from userspace, with no need for kernel modifications such as suspend > blockers. And since Android can reach essentially the same low-power > state from idle as from suspend, it appears that they really don't need > any kernel changes at all. > I don't think this is true. If you stop after the freezer phase you still need all the suspend blockers that are held until user-space consumes an event, otherwise it never gets consumed since user-space is frozen. -- 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/
From: Alan Stern on 7 Jun 2010 21:20 On Mon, 7 Jun 2010, Arve Hj�nnev�g wrote: > > Remember that suspend takes place in several phases, the first of which > > is to freeze tasks. �The phases can be controlled individually by the > > process carrying out a suspend, and there's nothing to prevent you from > > stopping after the freezer phase. �Devices won't get powered down, but > > Android uses aggressive runtime power management for its devices > > anyway. > > > > If you do this then the synchronization can be carried out entirely > > from userspace, with no need for kernel modifications such as suspend > > blockers. And since Android can reach essentially the same low-power > > state from idle as from suspend, it appears that they really don't need > > any kernel changes at all. > > > > I don't think this is true. If you stop after the freezer phase you > still need all the suspend blockers that are held until user-space > consumes an event, otherwise it never gets consumed since user-space > is frozen. No. You don't need to hold any suspend blockers; you merely need to unfreeze userspace. Once it is unfrozen, it will eventually consume the wakeup event. What you _do_ need to do is to prevent userspace from getting frozen again too soon. That's the purpose of the list of "active" wakeup sources. So long as the power manager believes a source is still active, it won't freeze anything. 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: Arve Hjønnevåg on 7 Jun 2010 21:40 2010/6/7 Alan Stern <stern(a)rowland.harvard.edu>: > On Mon, 7 Jun 2010, Arve Hj�nnev�g wrote: > >> > In fact it's possible to do this with only minimal changes to the >> > userspace, providing you can specify all your possible hardware wakeup >> > sources. �(On the Android this list probably isn't very large -- I >> > imagine it includes the keypad, the radio link(s), the RTC, and maybe >> > a few switches, buttons, or other things.) >> > >> > Here's how you can do it. �Extend the userspace suspend-blocker API, so >> > that each suspend blocker can optionally have an associated wakeup >> > source. >> > >> > The power-manager process should keep a list of "active" wakeup >> > sources. �A source gets removed from the list when an associated >> > suspend blocker is activated. >> > >> >> How do you do this safely? If you remove the active wakeup only when > > "remove the active wakeup" isn't a good way of expressing this. �You > remove the wakeup source from the power manager's list of active > sources. �This is just manipulation of a data structure internal to the > power manager; it doesn't affect the actual source. > >> activating the suspend blocker, you will never unblock suspend if >> another wakeup event happens after user-space blocked suspend but >> before user-space read the events. > > I'm not sure what you mean. �In this scheme userspace doesn't ever > block suspends. �Instead the power manager freezes and unfreezes all > the other processes. �And the system never suspends, it simply goes > idle for prolonged periods of time... with all processes frozen except > the power manager, and it sitting inside a poll() system call. > > It's true that under some exceptional circumstances the system would > never remove a wakeup source from the "active" list and then would > never go idle. �But exactly the same problem exists with wakelocks, if > the kernel activates a wakelock and there's no user process reading the > corresponding event queue. > No, you have a different problem. If you open an input device and issue the ioctl to enable the suspend blocker that blocks while the queue is not empty then don't read the event, that is a bug that is easy to fix. What you have is a race condition. If you read an event that occurred after you blocked the task freezing tasks will never get frozen again (until more events occur). >> Also, I'm not sure we can easily associate a wakeup event with a user >> space suspend blocker. For instance when an alarm triggers it is >> sometimes because of a user-space alarm and sometimes because an >> in-kernel alarm. > > That's okay. �The association is optional, and not all suspend blockers > will have an associated wakeup source. �(However, each wakeup source > that needs to percolate up into userspace -- i.e., that isn't handled > internally by the kernel -- should have at least one associated suspend > blocker.) �The purpose of these associations is to make explicit the > "handoff" in your original scheme, whereby a source would cause the > kernel to activate a wakelock until some user process activated its own > and then cleared the kernel's wakelock. �In your scheme, the connection > between the userspace wakelock and the wakeup source is implicit; in > my scheme it is explicit. > > For example, a process that uses a suspend blocker in order to read > keystrokes would obviously associate its suspend blocker with the > keypad-matrix wakeup source. > We have multiple input devices and one thread reading from them. Do all input devices that can generate wakeup events share a wakeup source? > Or take your example of an alarm. �To make it work in my scheme, each > user alarm would have to be implemented as a poll-able file descriptor. > Processes reading the descriptor would block until the alarm expires. > (I don't know of any driver that provides this sort of timer interface, > but it would be easy to write one. �You could think of it as applying > Unix's "Everything is a file" philosophy to alarms.) �Each of these > descriptors would then be a wakeup source, included among the sources > that the power manager polls for, and a suspend blocker could be > associated with it. > It seems you would need a way to pass the wakeup source id to use from user space to the driver and for this to work (ignoring the race if you allow multiple alarms per file) which seems like more work than using a suspend blocker. -- 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/
From: Valdis.Kletnieks on 7 Jun 2010 22:20
On Tue, 08 Jun 2010 01:17:13 +0200, Linus Walleij said: > So I would really like to know from the Android people why the > binder is in the kernel, after all. Could it *theoretically* be in > userspace, on top of some unix domain sockets, running as a > real-time scheduled daemon or whatever, still yielding the same > performance? Or is there some discovered limitation with current > interfaces, that everybody ought to know? Not an Android person, but... How expensive is a userspace->kernel transition on Android-class hardware? There's certainly something to be said for short-circuiting the path source_process -> kernel -> broker_process -> kernel -> dest_process down to the shorter source->kernel->dest |