On Wed, Aug 4, 2010 at 6:58 PM, Matt Helsley <matthltc@xxxxxxxxxx> wrote: > On Wed, Aug 04, 2010 at 05:35:09PM +0100, Matthew Garrett wrote: >> >> The main problem I see with the cgroups solution is that it doesn't seem >> to do anything to handle avoiding loss of wakeup events. > > cgroups alone don't but there is a solution which doesn't require routing > all event data through a single server -- use SIGIO. > > Suppose we've got two cgroups of tasks -- those in the initial freezer > cgroup and those in a freezer cgroup meant for power-naive apps. Let's > call the second cgroup the naive cgroup. > > One task -- let's call it the "waker" -- is in the initial cgroup is normaly > asleep waiting for SIGIO. Note it's not an "app" -- it's been trusted/blessed > to be a non-power-naive task. It will be signaled via SIGIO by the > applications which want to be unfrozen when an event comes in. > > When the power-naive app in the naive cgroup opens a file descriptor it's > going through the Android interpretter to make the syscall. The interpretter > can do fcntl() on the fd to cause SIGIO to be delivered to the waker task. > When the waker gets SIGIO it unfreezes the naive cgroup and thus wakes the > power-naive app. When the power-naive app wakes it will > poll/return-from-poll/read/return-from-read and thus retrieve the event. The Android execution model includes native code in addition to the dalvik VM, and in the future could include other runtimes -- there are many standard libraries that directly make posix file IO calls, and apps can bundle native libraries which can also directly make syscalls. It's not practical to instrument every piece of userspace code that opens a fd somehow to make additional fcntl calls in various places. Brian _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
