Re: Attempted summary of suspend-blockers LKML thread

From: david
Date: Mon Aug 02 2010 - 20:10:00 EST

On Mon, 2 Aug 2010, Paul E. McKenney wrote:

On Sun, Aug 01, 2010 at 10:06:34PM -0700, david@xxxxxxx wrote:
On Sun, 1 Aug 2010, Arjan van de Ven wrote:

I'm a little worried that this whole "I need to block suspend" is
temporary. Yes today there is silicon from ARM and Intel where suspend
is a heavy operation, yet at the same time it's not all THAT heavy
anymore.... at least on the Intel side it's good enough to use pretty
much all the time (when the screen is off for now, but that's a memory
controller issue more than anything else). I'm pretty sure the ARM guys
will not be far behind.

remember that this 'block suspend' is really 'block overriding the
fact that there are still runable processes and suspending anyway"

having it labeled as 'suspend blocker' or even 'wakelock' makes it
sound as if it blocks any attempt to suspend, and I'm not sure
that's what's really intended. Itsounds like the normal syspend
process would continue to work, just this 'ignore if these other
apps are busy' mode of operation would not work.

which makes me wonder, would it be possible to tell the normal idle
detection mechanism to ignore specific processes when deciding if it
should suspend or not? how about only considering processes in one
cgroup when deciding to suspend and ignoring all others?

Why not flesh this out and compare it to the draft requirements?
(I expect to be sending another version by end of day Pacific Time.)

The biggest issue I see right off-hand is that a straightforward
implementation of your idea would require moving processes from one
cgroup to another when acquiring or releasing a suspend blocker, which
from what I understand would be way to heavyweight. On the other hand,
if acquiring and releasing a suspend blocker does not move the process
from one cgroup to another, then you need something very like the
suspend-blocker mechanism to handle those processes that are permitted
to acquire suspend blockers, and which are thus not a member of the
cgroup in question.

That said, I did see some hint from the Android guys that it -might-
be possible to leverage cgroups in the way that you suggest might help
save power during times when suspend was blocked but (for example) the
screen was turned off. The idea would be to freeze the cgroup whenever
the screen blanked, even if suspend was blocked. The biggest issue
here is that any process that can hold a suspend blocker must never to
an unconditional wait on any process in this cgroup. Seems to me that
this should be possible in theory, but the devil would be in the details.

If I am misunderstanding your proposal, please enlighten me!

you are close, but I think what I'm proposing is actually simpler (assuming that the scheduler can be configured to generate the appropriate stats)

my thought was not to move applications between cgroups as they aquire/release the suspend-block lock, bur rather to say that any application that you would trust to get the suspend-block lock should be in cgroup A while all other applications are in cgroup B

when you are deciding if the system shoudl go to sleep because it is idle, ignore the activity of all applications in cgroup B

if cgroup A applications are busy, the system is not idle and should not suspend.

this requires that the applications in cgroup A actually go idle as opposed to simply releaseing the suspend-block lock, but it would mean that there are no application changes required for to move a system from the status "even if it's busy, go ahead ans suspend" to "this application is important, don't suspend if it's got work to do", it would just be classifying the application in one cgroup or the other.

This assumes that an application that you would trust to hold the suspend-block lock is going to be well behaved (if it isn't, how can you trust it to not grab the lock inappropriatly?)

David Lang
--
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/