> Yes, there's no problem so far. The question is how you guarantee that
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.
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 ?
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.
--
