> - 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:

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.