Re: Attempted summary of suspend-blockers LKML thread
From: Paul E. McKenney
Date: Wed Aug 04 2010 - 12:32:30 EST
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...
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,
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/