LWN: Comments on "Suspend blocker suspense"

Suspend blocker suspense

hingo — 2010-06-02T20:10:36+00:00

touche! :-)

Suspend blocker suspense

jrn — 2010-05-29T21:44:47+00:00

> By default, applications expect to run. If they are feeling nice, they should be able to declare to the kernel "There is some work I'd like to do, but its okay if you ignore me if you think its a good time to suspend."

The parent can take a suspend block and provide an interface for its children to request to relinquish it. Consider the result: what happens in the window after each child is spawned and before it makes that request? If a shell script spawns friendly processes in its inner loop, is that going to block suspend?

Extending the block-by-default behavior to drivers would make it even worse. Every driver would need to include code to stop blocking suspend or the author would receive angry complaints that it killed the ability to suspend.

If I understand correctly, suspend blockers affect both opportunistic suspend and deliberate requests by the user to suspend.

Suspend blocker suspense

k8to — 2010-05-28T06:11:47+00:00

Ah, but you were expecting that.

Suspend blocker suspense

talisein — 2010-05-27T17:56:27+00:00

It seems to me for opportunistic suspend to fit into the larger Linux ecosystem, "blocking suspend" should not be an opt-in activity but rather an opt-out.

By default, applications expect to run. If they are feeling nice, they should be able to declare to the kernel "There is some work I'd like to do, but its okay if you ignore me if you think its a good time to suspend."

Then we don't have paranoid people adding blockers all over the kernel and device tree; instead people will look for places where it is explicitly okay to unblock suspend. Meanwhile Android can implement the opt-in in their base classes, while Wakelocks become inverted. This also has the benefit of publishing an interface that desktop distros can leave enabled, and GNOME/KDE/everyone else can slowly identify the non-critical sections of their code.

Suspend blocker suspense

njd27 — 2010-05-27T10:18:57+00:00

As of this writing, Linus has not said what he intends to do.

I fully expect some kind of left-field solution that complete solves the problem in a way no-one was expecting...

Suspend blocker suspense

dlang — 2010-05-27T08:57:45+00:00

as far as I can tell this is explicitly disagreeing with your #3 requirement.

They are saying that many apps are badly written and so do things when they don't need to. So as a result, unless the app raises the suspend block, the system may decide to go to sleep, even if the app is busy doing things.

Suspend blocker suspense

neilbrown — 2010-05-27T08:46:45+00:00

There seem to be a few different issues here that get conflated and so
confuse the picture. I think I can pick out three things.

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.