Re: Attempted summary of suspend-blockers LKML thread, take three

Jesse Barnes
2010-08-17T00:55:03Z

On Mon, 16 Aug 2010 20:20:32 -0400
Ted Ts'o <tytso@mit.edu> wrote:

> On Mon, Aug 16, 2010 at 08:16:55AM -0700, Jesse Barnes wrote:
> > Fortunately in this case the problem doesn't seem to be fatal. We've
> > already established that the userland API portion of suspend blockers
> > could be implemented in userspace with a bit more work, given that the
> > kernel problems with suspend/resume and events are addressed.
> > Hopefully Google is already developing a prototype userspace
> > implementation to make sure it's workable; being able to build stock
> > upstream kernels for my Droid and its Android userspace sure would be
> > nice.
>
> You know, you don't have to wait for the Android engineers to do this
> work. You (or others who want to be able to use stock upstream kernel
> with Android devices) could just as easily try to do the "bit more
> work" yourselves --- that is, do the open souce thing and scratch
> one's own itch.

Sure, I could. And the Google guys could put together a whole Debian
distro with suspend blockers sprinkled throughout various apps. But
for my part, I can't justify that kind of work at the moment. Of
course I'd be happy if someone could and did do the work, it would be a
useful exercise and potentially allow Android to work well on stock
kernels.

> After all, Rafael is saying he's refusing to accept patches (or
> implement) in-kernel oppunsitic suspend for upstream unless it's
> proven to him that a userspace implementation isn't sufficient. It
> might be just as fair for the Android userspace upstream to refuse to
> accept (or engineer) userspace changes unless it is proven that the
> userspace version of opporunistic suspend is just as good as the
> in-kernel version which is successfully been deployed in millions and
> millions of shipping units today...
>
> Speaking personally, it's not clear to me how waking up a userspace
> suspend daemon and waiting for it to get scheduled will result in
> better power savings than simply handling it in the kernel, but as
> soon as someone is willing to do the work, we can find out for sure
> who is right.

Yeah it would add some overhead, since suspend blocker calls would use
IPC to a userspace daemon, which would also be responsible for
(periodically?) waking up to see if the system ought to be
suspended... I agree coding it up would be a useful exercise.

--
Jesse Barnes, Intel Open Source Technology Center