Thread (1 message) 1 message, 1 author, 2010-08-03

Re: Attempted summary of suspend-blockers LKML thread

From: Paul E. McKenney <hidden>
Date: 2010-08-03 14:11:13

On Mon, Aug 02, 2010 at 09:56:10PM -0700, Arve Hjønnevåg wrote:
On Sun, Aug 1, 2010 at 6:10 PM, Paul E. McKenney
[off-list ref] wrote:
quoted
On Sun, Aug 01, 2010 at 03:47:08PM -0700, Arjan van de Ven wrote:
...
quoted
quoted
Another one: freezing whole cgroups..... we have that today. it
actually works quite well.... of course the hard part is the decision
what to put in which cgroup, and at what frequency and duration you let
cgroups run.
Indeed, the Android guys seemed to be quite excited by cgroup freezing
until they thought about the application-classification problem.
Seems like it should be easy for some types of applications, but I do
admit that apps can have non-trivial and 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.
Excellent point -- I had completely missed this failure mode!!!

							Thanx, Paul
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help