On Thu, May 27, 2010 at 3:55 PM, Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> wrote: > > This started because the Android people came to a meeting that was put > together of various folks to try and sort of the big blockage in getting > Android and Linux kernels back towards merging. > > I am interested right now in finding a general solution to the Android > case and the fact it looks very similar to the VM, hard RT, gamer and > other related problems although we seem to have diverged from that logic. I think that the suspend block model can be viewed as a constraints problem (similar to some of things things you've been sketching out in these threads), but I think we (Google/Android) view it as more of a state constraint (don't enter suspend) than a latency constraint. We think there's a need for these constraints both from the driver side and userspace side, and that these constraints are not tied to processes (multiple entities in one process may have different constraints at different times or multiple processes may be working together to accomplish some goal under a single constraint -- at least both cases exist in the Android system as it ships today). The exact naming of the API is not terribly important to us. The first thing we spent a bunch of time discussing last summer when Arve first looked into sending wakelocks upstream was changing the name because many objected to "wakelock" for various reasons. Being able to have userful statistics (which drivers/processes/etc held which wakelock for how long, how many times, etc) is important to us. While we want to do the best we can in the face of poorly written apps, we also want to educate users and developers about which apps are contributing to their poor battery life -- so users can decide to uninstall an app if its usefulness does not justify its impact on battery life and application developers can be more aware of what the cost of their app is to endusers. As an example, http://frotz.net/misc/battery-stats-unplugged.txt contains a dump from the "battery service" aggregating wakelock usage, cpu usage, and sensor device usage of processes (#....: sections) on my phone the other day for a ~3 hour period. This data is presented visually to the enduser in a "what's using my battery" feature of the platform. "realtime" refers to wall clock time here and "uptime" refers to not-in-suspend execution time. Brian -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
