[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100803183447.0275c134@infradead.org>
Date: Tue, 3 Aug 2010 18:34:47 -0700
From: Arjan van de Ven <arjan@...radead.org>
To: Arve Hjønnevåg <arve@...roid.com>
Cc: paulmck@...ux.vnet.ibm.com, linux-pm@...ts.linux-foundation.org,
linux-kernel@...r.kernel.org, mjg59@...f.ucam.org, pavel@....cz,
florian@...kler.org, rjw@...k.pl, stern@...land.harvard.edu,
swetland@...gle.com, peterz@...radead.org, tglx@...utronix.de,
alan@...rguk.ukuu.org.uk
Subject: Re: Attempted summary of suspend-blockers LKML thread
On Mon, 2 Aug 2010 21:56:10 -0700
Arve Hjønnevåg <arve@...roid.com> 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...
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists