On Thu, 27 May 2010 17:07:14 +0100
Matthew Garrett <mjg59@srcf.ucam.org> wrote:

quoted text
> On Thu, May 27, 2010 at 04:05:43PM +0100, Alan Cox wrote:
> > > 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 
> > 
> > I would hope not, because I'd rather prefer my app that used the screen
> > to get the chance to save important data on what it was doing
> > irrespective of the screen blank:  "I have an elegant proof for this
> > problem but my battery has gone flat"
> 
> Perhaps set after callbacks are made. But given that the approach 
> doesn't work anyway...

Which approach doesn't work, and why ?

quoted text
> > What is the problem here - your device driver for the display can block
> > tasks it doesn't want to use the display.
> 
> It's still racy. Going back to my example without any of the suspend 
> blocking code, but using a network socket rather than an input device:
> 
> int input = socket(AF_INET, SOCK_STREAM|SOCK_NONBLOCK, 0);
> char foo;
> struct sockaddr addr;
> connect (input, &addr, sizeof(addr))
> while (1) {
>        if (read(input, &foo, 1) > 0) {
>                (do something)
>        } else {
>                (draw bouncing cows and clouds and tractor beams briefly)
>        }
> }
> 
> A network packet arrives while we're drawing. Before we finish drawing, 
> the policy timeout expires and the screen turns off.

Which is correct for a badly behaved application. You said you wanted to
constrain it. You've done so. Now I am not sure why such a "timeout"
would expire in the example as the task is clearly busy when drawing, or
is talking to someone else who is in turn busy. Someone somewhere is
actually drawing be it a driver or app code.

For a well behaved application you are drawing so you are running
drawing stuff so why would you suspend. The app has said it has a
latency constraint that suspend cannot meet, or has a device open that
cannot meet the constraints in suspend.

You also have the socket open so you can meaningfully extract resource
constraint information from that fact.

See it's not the read() that matters, it's the connect and the close. 

If your policy for a well behaved application is 'thou shalt not
suspend in a way that breaks its networking' then for a well behaving app
once I connect the socket we cannot suspend that app until such point as
the app closes the socket. At any other point we will break the
connection. Whether that is desirable is a policy question and you get to
pick how much you choose to trust an app and how you interpret the
information in your cpufreq and suspend drivers.

If you have wake-on-lan then the network stack might be smarter and
choose to express itself as

	'the constraint is C6 unless the input queue is empty in which
	 case suspend is ok as I have WoL and my network routing is such
	 that I can prove that interface will be used'

In truth I doubt much hardware can make such an inference but some phones
probably can. On the other hand for /dev/input/foo you can make the
inference very nicely thank you.

Again wake on lan information does not belong in the application !



--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/