On Thu, 27 May 2010, Matthew Garrett wrote:
> 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.
Thanks for providing this example:
1) It proves that suspend blockers are solely designed to encourage
people to code crap.
2) It exposes the main conceptual problem of the approach:
The input layer in the kernel magically takes a suspend blocker
and releases it in an equally magic way just to allow the crappy
application to reach the point where it takes it's own suspend
blocker and can react on the user input.
And you need to do that, because the user applications suspend
blocker magic is racy as hell. To work around that you sprinkle
your suspend blocker magic all over the kernel instead of telling
people how to solve the problem correctly.
And what are you achieving with this versus power saving ?
Exaclty _NOTHING_ !
Simply because you move the cow drawing CPU time from the point
where the device wants to go into suspend to the point where the
user hits a key again. You even delay the reaction of your app to
the user input by the time it needs to finish drawing cows.
So you need to come up with a way better example why you need
your blockers than with this prove of misconception.
> 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.
Wrong. If your application is interactive then you set the QoS
requirement once to interactive and be done.
So the correct point to make a power state decision is when the app
waits for a key press. At this point the kernel can take several
pathes:
1) Keep the system alive because the input device is in active
state and a key press is expected
2) Go into supsend because the input device is deactivated after
the screen lock kicked in.
This behaves exactly the same way in terms of power consumption as
your blocker example just without all the mess you are trying to
create.
And it allows the kernel to use intermediate power saving methods
(between idle and suspend) which might be available on some hardware.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
