2010/6/5 Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>: > On Sat, 5 Jun 2010, Arve Hjønnevåg wrote: > >> Yes, we can keep all our user space suspend blockers and thaw the >> frozen cgroup when any suspend blocker is held, but this would >> eliminate any power advantage that freezing a cgroup has over using >> suspend to freeze all processes. Without annotating the drivers to >> block the cgroup freezing in the same places as we now block suspend, >> it also prevents processes in the cgroup that we freeze from directly >> consuming wakup events. > > The driver annotations don't need to block the cgroup freezing. They > just need to keep the system running long enough to awaken a thread > that will handle the wakeup event. (See below.) A pm-qos constraint > is good enough for this. > I'm not sure what you mean by this, either you need to annotate the drivers or you don't. >> 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. > This breaks existing apps. It effectively requires that a process that use suspend blocker do no work that does not block suspend. > 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. > This would create a minefield of possible deadlocks. You now have to make sure that your trusted threads do not share any locks with your untrusted threads. For instance you cannot safely call into the heap while any threads in your process are frozen. > 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. > >> And, it >> does not solve the problem for systems that enters lower power states >> from suspend than it can from idle. The last point my not be relevant >> to android anymore, but desktop systems already have auto suspend and >> it would be preferable to have a race free kernel api for this. > > This is an entirely different matter from the rest of the discussion. > It would be better to consider this separately after Android's current > problems have been addressed. > Yes there has not been much discussion about this, but I don't understand why not. Automatic suspend is used outside Android, and it has the same race conditions that suspend blockers fix. -- 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
