Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett <mjg59@srcf.ucam.org>]

On Thu, May 27, 2010 at 12:39:43AM +0100, Alan Cox wrote:

> - Supporting Android needs well good
> - Opportunistic suspend good
> - Manner in which interface is expressed to userspace bad
> - Latency constraint interface would be better
> - Your existing behaviour can be implemented by a simplistic use of a
>   latency constraint interface
> - We can fix a pile of other directly connected things at the same time
> - Implementation internals I care far less about because we can fix those
>   later
> - Suspend is just a power state
> 
> How does that fit your model and vision ?

I don't entirely see how this works. In order to deal with poorly 
written applications, it's necessary to (optionally, based on some 
policy) ignore them when it comes to the scheduler. The problem is how 
to implement the optional nature of this in a race-free manner. This is 
obviously a pathological case, but imagine an application that does 
something along the following lines:

int input = open ("/dev/input", O_RDONLY|O_NONBLOCK);
char foo;

while (1) {
	suspend_block();
	if (read(input, &foo, 1) > 0) {
		(do something)
		suspend_unblock();
	} else {
		suspend_unblock();
		(draw bouncing cows and clouds and tractor beams briefly)
	}
}

Now, if the user is playing this game, you want it to be scheduled. If 
the user has put down their phone and the screen lock has kicked in, you 
don't want it to be scheduled. So we could imagine some sort of cgroup 
that contains untrusted tasks - when the session is active we set a flag 
one way which indicates to the scheduler that tasks in TASK_RUNNING 
should be scheduled, and when the session is idle we set the flag the 
other way and all processes in that cgroup get shifted to 
TASK_INTERRUPTIBLE or something.

Except that doesn't work. If the session goes idle in the middle of the 
app drawing a frame, we'll stop the process and the task will never call 
read(). So the user hits a key, we wake up, nothing shifts from 
TASK_INTERRUPTIBLE into TASK_RUNNING, the key never gets read, we go 
back to sleep. The event never gets delivered.

Now let's try this in the Android world. The user hits a key and the 
system wakes up. The input layer takes a suspend block. The application 
now draws all the cows it wants to, takes its own suspend block and 
reads the input device. This empties the queue and the kernel-level 
suspend block is released. The application then processes the event 
before releasing the suspend block. The event has been delivered and 
handled.

You can't express that with resource limits or QoS constraints. If you 
want to deal with this kind of situation then, as far as I can tell, you 
need either suspend blockers or something so close to them that it makes 
no difference.

-- 
Matthew Garrett | mjg59@srcf.ucam.org