Re: Attempted summary of suspend-blockers LKML thread

Matt Helsley
2010-08-05T03:25:56Z

On Wed, Aug 04, 2010 at 07:02:55PM -0700, Brian Swetland wrote:
> On Wed, Aug 4, 2010 at 6:58 PM, Matt Helsley <matthltc@us.ibm.com> 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.

Perhaps using an LD_PRELOAD will work.

Cheers,
-Matt Helsley