Suspend blocker suspense

The context is, of course, that we want to get to a low power state as
quickly as possible, but lower power states tend to have larger
latencies for resuming operation and that can sometimes be a problem.

So the three issues are:

1/ Some application may "know" that it needs low latency. i.e. it is
busy doing something useful for the device owner and shouldn't be
forced into an unduly low power state. Thus it will want to "block
suspend".

2/ An event may arrive (incoming call, button press, etc) at the
kernel level, and the kernel needs to ensure that this event gets
adequately responded to before we drop into a low power state.
e.g. for an incoming call, the kernel needs to keep the phone from
suspending until the gui has had a chance to notice the call and so
request it's own suspend-block.

3/ Maybe we shouldn't be suspending anyway. If any process is active,
then it should be able to run. Hardware should (and supposedly new
hardware does) use as little power if a non-suspend deep sleep as it
does in full suspend so there should be no need for suspend.
I'm not sure I have that argument exactly right. Maybe suspend is OK
if we "know" that any important interrupt will wake from suspend, and
that we "know" how long to the next timer event and can program a
wakeup for that time.

The "suspend blocker" proposal seems to conflate the first two and
adds the assumption that the required minimum latency that an app can
ask for is either all or nothing. It ignores the third, or maybe
explicitly disagrees with it, saying that processes have no right to
expect to keep running unless they explicitly ask for (and pay for)
that right.

On top of that there are subtleties about how an app might express its
latency requirements, whether it might be just another ulimit or
whether something else might be needed.

So on the whole I'm not surprised that the discussion isn't getting
anywhere as you can always find one part of the big complex issue that
a particular proposal doesn't address, and attack it on that basis.

I think it is important to clearly define the problem first (didn't
Einstein say that?) and in this case I think we have several problems
that need to be separated - quite probably more than just these three.