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 | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
