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

[Alan Cox <alan@lxorguk.ukuu.org.uk>]

> I'm not saying that your argument is not valid. But why don't you look
> at suspend blockers as a contract between userspace and kernelspace? An
> Opt-In to the current guarantees the kernel provides in the non-suspend
> case.

It is a contract - but not the right one. You are removing autonomy from
the kernel when only the kernel can measure the full picture and when the
kernel is actually supposed to be responsible for resource management.

> On the other hand, applications can say, they don't need that much
> power and userspace guaranties and not take a suspend blocker.

Even the the model is wrong.

> I don't think opportunistic suspend is a policy decision by the kernel.
> it is something new. Something which currently only the android

Disagree. It's an arbitary and misleading divide that happens to reflect
a specific vendors current phones. Worse yet it may not reflect their own
future products. It assumes for example that their is some power level
that is 'suspend' that is singular, application understood and can be
effectively user space managed. Big assumptions and not ones that seem to
be sensible.

It also breaks another rule - when the hardware changes your application
blocker policies will be wrong. Do you want multiple hand optimised
copies of each app ? Take a look at what happened to CPU designs where
the assumption was you'd recompile the app for each CPU version to get
any useful performance.

If you are instead expressing it as "must be able to respond in time X"
and "must be able to wake up from an event on an active device" then your
interface is generic and hardware independant.

If "bouncing cows" says 'need to wake up every 0.3 seconds" you want the
kernel to decide how best to do that. It will vary by hardware. On todays
desktop PC thats probably a low power state limit. On some current
embedded hardware it might be a special deep sleep mode. On one or two
devices it might be 'suspend'. It might also be that the properties have
been set to 2 seconds already so it gets told it can't have 0.3.

The app cannot be allowed to know platform specific stuff or your
portability comes apart and you end up with a disaster area where each
app only comes on a subset of devices. Express the requirement right and
you get a simple clean interface that continues to work.

Express it wrong and you get a mess.

> userspace implements / supports. If you don't want to suspend while
> looking at the bouncing-cow, you have to take a suspend blocker and
> make yourself a user-visible power-eater, or don't do 

Thats a very big hammer and it doesn't express what I actually want,
which is to allow the cows to run as efficiently as possible.
> 
> echo "opportunistic" > /sys/power/policy 
> 
> in the first place.

But you can do this properly by having a per process idle requirement,
and that can encompass things like hard real time as well (or even
gaming). The suspend blockers break all the global policy, don't solve
real time and don't allow for sensible expansion models. They don't solve
our existing wakeup versus device problems either.

> How does this address the loss of wakeup events while using suspend? 
> (For example the 2 issues formulated by Alan Stern in [1])

In this environment the problem cannot occur in the first place unless
there are kernel code bugs, if there are then they are in GPL code and can
be fixed. But you are mixing up interfaces and implementations which I
find is usually a bad idea. Doing the right thing badly gives you an
interface to an implementation you can later fix. Doing the wrong thing
well leaves you stuck down a hole.

> p.s.: 
> dmk@schatten /usr/src/linux $ grep -r "setpidle" .

Yes I know - no point having a new function which has an in use name is
there ? It's trivial to add per process idling or wakeup requirements.

Alan