See, NOW it makes sense...

Posted Feb 8, 2010 5:56 UTC (Mon) by swetland (guest, #63414)
In reply to: See, NOW it makes sense... by mjg59
Parent article: Greg Kroah-Hartman: Android and the Linux kernel community

Yeah, I consider the binder a side-issue. In theory one could replace it entirely, if one were willing to write a bunch of userspace code that accomplished everything userspace needs from it, etc, etc, and it is self-contained and no other drivers depend on it.

I thought we had actually explained a number of situations where wakelocks provide value beyond existing solutions -- I'll have to dig through the linux-pm threads and try to extract some stuff from there. One thing we're looking to do is put together a clean writeup of the "why" behind all this as a basis for discussion.

I don't see how retention from idle (which we do as well) fully solves the problem -- since you can easily have situations, in an environment where you can't control every process/thread (300+ threads in a typical android system at boot -- yeah, kinda crazy, but it is what it is). Going to suspend means we don't need to worry about non-optimal software with polling/periodic behaviors causing the CPU to wake up more often than ideal. Also, you still have situations in which you *can't* go to full retention in idle because of a driver being busy (which is what idlelocks -- just another class of wakelock) are about.

I think it would be extremely valuable to get some folks together somewhere and try to hash some of this out. In general we are not opposed to slightly different ways of doing things as long as we accomplish what we need to accomplish power-wise. I mean, Arve's already respun the wakelock API (now suspend_blocker, no?) several times in response to various feedback.

I'd love to engage in a forum where the goal is to solve common problems rather than assign blame -- Greg's blogpost implying that he's giving a CELF keynote about how we suck does not create much enthusiasm on our side for attending, for example.

We know that some people would have been happier if we worked out a design for all of this before 1.0 shipped, but that didn't happen, and arguing about how practical it would have been or not doesn't really gain anybody anything. Figuring out how to collaborate on things so that future issues get sorted out earlier and more smoothly seems entirely worthwhile though.

So when/where is the next time/place that we could meet up with the other interest parties on the linux-pm front and talk about these things?

See, NOW it makes sense...

Posted Feb 8, 2010 6:34 UTC (Mon) by mjg59 (subscriber, #23239) [Link]

Right, it's absolutely true that the wakelock approach simplifies the userspace implementation,
but we could take a different view of things - at the most aggressive level, you could keep a
userspace wakelock implementation and use the uswsusp interface to fire off the process
freezer when all of them are released. All we'd need then would be a mechanism to provide a
list of PIDs that you don't want frozen.

The drivers side of thing is more interesting, and I think that's something that could potentially
be implemented using Rafael's runtime suspend work. As long as the dependencies are
expressed (and I admit that doing so is problematic right now), a busy driver can do a
pm_runtime_get() and then a pm_runtime_put() when it's idle again. Letting that information flow
up the tree could then allow the platform code to inhibit entry to the deeper states. TI seem to
do this in a more hacky way by simply using the systemwide busmastering flag, which cpuidle will
then use to limit idle to wfi-type states. It's not elegant, but it works.

The next linux pm summit is planned for Boston in August, which is kind of far away. There's the
collab summit in SF in April which isn't generally a highly technical conference but is co-hosted
with CELF this year. I suspect we could probably sort something out for that, if there's interest,
and it's the kind of thing that the Linux Foundation would probably love to make happen.