On Tue, Aug 03, 2010 at 06:34:47PM -0700, Arjan van de Ven wrote: > On Mon, 2 Aug 2010 21:56:10 -0700 > Arve Hjønnevåg <arve@xxxxxxxxxxx> wrote: > > > > non-obvious dependencies. > > > > > > > The dependencies is what made this solution uninteresting to us. For > > instance, we currently use cgroup scheduling to reduce the impact of > > some background tasks, but we occasionally saw a watchdog restart of > > the system process were critical services were waiting on a kernel > > mutex owned by a background task for more than 20 seconds. If we froze > > a cgroup instead, we would not hit this particular problem since tasks > > cannot be frozen while executing kernel code the same way they can be > > preempted, but nothing prevents a task from being frozen while holding > > a user-space resource. > > one of the solutions we're looking at to solve this is to unfreeze the > cgroup on a regular basis (say, every 15 to 30 seconds) briefly to avoid > this kind of deadlock... Cute!!! ;-) If this doesn't work for the Android folks for whatever reason, another approach would be to do the freeze in user code, which could track whether any user-level resources (pthread mutexes, SysV semas, whatever) where held, and do the freeze on a thread-by-thread basis within each "victim" application as the threads reach safe points. I must of course defer to the Android folks as to whether or not this would actually work for Android. But if your approach works for them, why worry? Thanx, Paul _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
