On Thu, 27 May 2010 02:07:21 -0700
Arve Hjønnevåg <arve@xxxxxxxxxxx> wrote:
> >
> >> of it into pm QoS stuff and if one day someone solves the rogue app
> >> problem, we can migrate over.
> >
> > If it's so important for Android and no one else, Android can carry it
> > out of tree.
> >
>
> This is not only important for Android. If you use suspend on a
> current Linux system you run the risk of loosing wakeup events. If you
> have wakeup events that you cannot afford to lose your only option is
> to never suspend. On some hardware (e.g. x86) the cost of not
> suspending is always huge, on other hardware (many ARM SOCs) the cost
> is only huge if your apps behave poorly.
>
So here is my suggestion.
Rather than trying to push a feature that is clearly meeting lots of
resistance, the Android devs should state the problem as a bug that needs
fixing. As you have.
Upstream is a lot more receptive of fixing bugs than adding features.
In this case the bug is that you cannot suspend without the risk of losing
wakeup events. This is a real bug that for your use case is a serious
bug. I've toyed with several ways of fixing this but the one that seems most
promising is to note that in the kernel the suspend process is two-stage with
a 'prepare' followed by a 'suspend'. Userspace cannot make that distinction
and so ends up with a race.
Maybe userspace should be able to say "prepare to suspend" with the meaning
that after a successful return, any event which would cause a wakeup sets a
flag so that the final suspend returns immediately (without actually going to
the lower power state).
Then your opportunistic suspend could be entirely in userspace where you
wouldn't have to fight with the kernel crowd :-)
The suspend-daemon would:
Wait for all user-space suspend blocks to be dropped.
Tell the kernel to "prepare to suspend".
Tell all userspace programs which have registered for the message that they
should prepare to suspend. They have the opportunity at this point to
take out a new suspend block if they notice an event that has
just arrived
Wait for all those programs to acknowledge
If there are no new suspend blocks, tell the kernel to suspend
else tell the kernel to abort the suspend.
This (I think) allows race-free opportunistic suspend in user-space where
you can do all the accounting you need.
I don't fully understand your requirements for accounting of devices drivers
rejecting or blocking a suspend, so I cannot say precisely how that would fit
in. Maybe you just need to know - whenever the 'suspend request' completes -
what the wakeup events were. It shouldn't be too hard to export that to
user-space via sysfs.
I won't propose an exact enhancement to the user-space interface for
requesting a suspend, but I suspect it should expose each of
suspend_prepare
suspend_devices_and_enter
suspend_finish
(or close analogues there-of) to user-space. It is tempting to map those to
"open-for-write", "write", "close", but I'm not sure that suspend_prepare
would be appropriate if the app was about to write "disk" - it is a pity that
both suspend and hibernate use the same sysfs file.
So just fix the bug, and everyone will be happy :-)
Thanks,
NeilBrown
_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/linux-pm
