2010/6/6 Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>: > On Sat, 5 Jun 2010, Alan Stern wrote: > >> > If you are referring to the approach that we don't use suspend but >> > freeze a cgroup instead, this only solves the problem of bad apps. It >> > does not help pause timers in trusted user space code and in the >> > kernel, so it does not lower our average power consumption. >> >> You can solve this problem if you restructure your "trusted" apps in >> the right way. Require a trusted app to guarantee that whenever it >> doesn't hold any suspend blockers, it will do nothing but wait (in a >> poll() system call for example) for a wakeup event. When the event >> occurs, it must then activate a suspend blocker. >> >> Better yet, make it more fine-grained. Instead of trusted apps, have >> trusted threads. Freeze the untrusted threads along with everything >> else, and require the trusted threads to satisfy this guarantee. >> >> In this way, while the system is idle no user timers will get renewed. >> Kernel timers are another matter, but we should be able to handle them. >> There's nothing Android-specific about wanting to reduce kernel timer >> wakeups while in a low-power mode. > > In fact it's possible to do this with only minimal changes to the > userspace, providing you can specify all your possible hardware wakeup > sources. (On the Android this list probably isn't very large -- I > imagine it includes the keypad, the radio link(s), the RTC, and maybe > a few switches, buttons, or other things.) > > Here's how you can do it. Extend the userspace suspend-blocker API, so > that each suspend blocker can optionally have an associated wakeup > source. > > The power-manager process should keep a list of "active" wakeup > sources. A source gets removed from the list when an associated > suspend blocker is activated. > How do you do this safely? If you remove the active wakeup only when activating the suspend blocker, you will never unblock suspend if another wakeup event happens after user-space blocked suspend but before user-space read the events. Also, I'm not sure we can easily associate a wakeup event with a user space suspend blocker. For instance when an alarm triggers it is sometimes because of a user-space alarm and sometimes because an in-kernel alarm. > When the "active" list is empty and no suspend blockers are activated, > the power manager freezes ALL other processes, trusted and untrusted > alike. It then does a big poll() on all the wakeup sources. When the > poll() returns, its output is used to repopulate the "active" list and > processes are unfrozen. > > (You can also include some error detection: If a source remains on the > "active" list for too long then something has gone wrong.) > > To do all this you don't even need to use cgroups. The existing PM > implementation allows a user process to freeze everything but itself; > that's how swsusp and related programs work. > > This is still a big-hammer sort of approach, but it doesn't require any > kernel changes. > > Alan Stern > > -- Arve Hjønnevåg -- 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
