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

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

On Thu, May 27, 2010 at 07:02:04PM +0100, Alan Cox wrote:
> > This is still racy. Going back to this:
> > 
> > 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 {
> > 		* SUSPEND OCCURS HERE *
> 
> Fine but then the packet will arrive and we will wake back up process the
> packet and wake the task. See suspend is just like a deep sleep. If we
> went to sleep there and the packet arrival doesn't rewake the box the
> driver was buggy.

Yes, there's no problem so far. The question is how you guarantee that 
the application has had the opportunity to handle the packet.

> > reaches the end of its timeslice. At this point the application has not 
> > had an opportunity to indicate in any way whether or not the packet has 
> > altered its constraints in any way. What stops us from immediately 
> > suspending again?
> 
> If my app level constraint before the packet is 'don't suspend' then my
> constraint on receipt is 'don't suspend' so I won't suspend. If my
> constraint is then lowered and I suspend I will suspend *after* the
> lowering.

If the app level constraint before the packet was "don't suspend", we 
wouldn't have suspended. Here's a description of the desired behaviour 
of the application as you requested:

The application is a network monitoring app that renders server state 
via animated bouncing cows. The desired behaviour is that the 
application will cease to be scheduled if the session becomes idle 
(where idle is defined as the system having received no user input for 
30 seconds) but that push notifications from the server still be 
received in order to allow the application to present the user with 
critical alerts.

Under Android:

User puts down phone. 30 seconds later the screen turns off and releases 
the last user-level suspend block. The phone enters suspend and the 
application is suspended. A network packet is received, causing the 
network driver to take a suspend block. The application finishes the 
frame it was drawing, takes its own suspend block and reads the network 
packet. In doing so the network driver releases its suspend block, but 
since userspace is holding one the phone stays awake. The application 
then handles the event as necessary, releases its suspend block and the 
phone goes to sleep again.

I don't see how this behaviour can be emulated in your model.

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