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

[Alan Cox]

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

Because the application has said that it wants QoS guarantees. It wants
to know that if the events it can receive occur it will wake up within
the timescale.

So it receives the event. It's now running, not idle so we won't suspend
it.

At some point in time it will become idle again _or_ the CPU limit will
get it.


If the app is not trusted then we might suspend it before it handles the
packet. That is fine, it's not trusted and we will do that when we decide
its in the system interest to suspend it anyway.

You still don't lose the event because on resume the task will do its
processing.


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

This is a bit confusing - does the screen come back on for such events,
what constraints is the server operating under ? How does your code look
- it's hard to imagine the examples you've given as being workable given
they would block on network packet wait when a critical event occurs.
Are you using poll or threads or what ?

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

User puts down phone. 30 seconds later the X server decides to turn the
screen off and closes the device. This probalby releases the constraint
held via the display driver not to suspend. Any further draw requests will
block.

System looks at the other tasks and sees they are idle and can sink to a
low power state. Cows is either blocked on a packet receive or could even
be blocked on writing to the display (or both if its a realistic example
and using poll)

Everyone is idle, we can sleep

The kernel looks at the constraints it has
	- must not sink to a state below which network receive of packets
	  fails
	- must not sink below a state where whatever is needed for the
	  critical alert code etc to do its stuff
	- must not sink to a state which takes more than [constraint]
	  seconds to get back out of

It picks 'opportunistic suspend'
It goes to sleep

A packet arrives
It wakes the hardware
We are busy, we do not wish to suspend
It processes the packet
It wakes the user app
It starts processing the packet
[We are busy, we do not wish to suspend]

Presumably your display server listens to waking back up and decides to
re-activate the screen (your example is unclear and implies it carries on
processing the extra frame in the dark which seems a bit silly ?

I still don't see a problem. 

I think your problem arises because you start from the basis that forcing
suspend is special. As Thomas has said there are working implementations
where suspend is an idle mode.

The moment you discard that specific notion everything works, as it does
today on other embedded platforms.

Now what do you do if the app is burning too much processor time. That's
a QoS question too. We've got cpu limits, we've got SIGXCPU, we don't
have "cpu per second" type limits but that isn't hard to do either.

Stop transitioning Run->Forced Suspend. If you've got stuff stuck running
then deal with it by constraining it to go idle or by blowing it out of
the water. PM will then do the rest.

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