From: Thomas Gleixner on
On Sat, 5 Jun 2010, Arve Hj�nnev�g wrote:
> 2010/6/5 Thomas Gleixner <tglx(a)linutronix.de>:
> >
> > Can you please explain in a consistent way how the application stack
> > and the underlying framework (which exists according to android docs)
> > is handling events and how the separation of trust level works ?
> >
>
> I don't think I can, since I only know small parts of it. I know some

Sigh, thats the whole reason why this discussion goes nowhere.

How in heavens sake should we be able to decide whether suspend
blockers are the right and only thing which solves a problem, when the
folks advocating suspend blockers are not able to explain the problem
in the first place ?

> events like input event go though a single thread in our system
> process, while other events like network packets (which are also
> wakeup events) goes directly to the app.

Yes, we know that already, but that's a completely useless information
as it does not describe the full constraints and dependencies.

Lemme summarize:

Android needs suspend blockers, because it works, but cannot explain
why it works and why it only works that way.

A brilliant argument to merge them - NOT.

Thanks,

tglx
From: Alan Cox on
On Sun, 6 Jun 2010 12:46:01 +0200
Florian Mickler <florian(a)mickler.org> wrote:

> On Sun, 6 Jun 2010 12:00:47 +0200
> Vitaly Wool <vitalywool(a)gmail.com> wrote:
>
> > Even worse, the suspend wakelock will keep the
> > whole kernel active, as opposed to powering off unused devices
> > separately as it's done in runtime PM.
>
> That is not true. While the kernel is not suspended it does
> runtime pm.

On several of our platforms runtime PM already includes suspend so a
suspend wakelock does interfere with existing power managemet at that
level (not to mention the maintenance mess it causes).

This is one of the reasons you want QoS information, it provides
parameters by which the power management code can make a decision.
Suspend blocksers simply don't have sufficient variety to manage the
direction of power policy.

If Android chooses to abuse the QoS information for crude suspend
blocking then that is fine, it doesn't interfere with doing the job
'properly' on other systems or its use for realtime work on other boxes.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Vitaly Wool on
2010/6/6 Florian Mickler <florian(a)mickler.org>:

> Suspend_blockers allow the system to suspend ("mem">/sys/power/state
> suspend), when the userspace decides that the device is not in use.

Sorry. What? Blockers allow the system to suspend?

> So implementing suspend_blockers support does not impact any
> optimizations done to either system A nor system B.

Suspend blockers by themselves are of no use. Completely. So any talks
on suspend blockers separated from the sleep policy are completely
pointless.
The suspend blockers are of use when the userspace tries to blindly
freeze the tasks to enter the suspend state. This way of hammering the
system down obviously impacts everything.

~Vitaly
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Alan Stern on
On Sat, 5 Jun 2010, Alan Stern wrote:

> > If you are referring to the approach that we don't use suspend but
> > freeze a cgroup instead, this only solves the problem of bad apps. It
> > does not help pause timers in trusted user space code and in the
> > kernel, so it does not lower our average power consumption.
>
> You can solve this problem if you restructure your "trusted" apps in
> the right way. Require a trusted app to guarantee that whenever it
> doesn't hold any suspend blockers, it will do nothing but wait (in a
> poll() system call for example) for a wakeup event. When the event
> occurs, it must then activate a suspend blocker.
>
> Better yet, make it more fine-grained. Instead of trusted apps, have
> trusted threads. Freeze the untrusted threads along with everything
> else, and require the trusted threads to satisfy this guarantee.
>
> In this way, while the system is idle no user timers will get renewed.
> Kernel timers are another matter, but we should be able to handle them.
> There's nothing Android-specific about wanting to reduce kernel timer
> wakeups while in a low-power mode.

In fact it's possible to do this with only minimal changes to the
userspace, providing you can specify all your possible hardware wakeup
sources. (On the Android this list probably isn't very large -- I
imagine it includes the keypad, the radio link(s), the RTC, and maybe
a few switches, buttons, or other things.)

Here's how you can do it. Extend the userspace suspend-blocker API, so
that each suspend blocker can optionally have an associated wakeup
source.

The power-manager process should keep a list of "active" wakeup
sources. A source gets removed from the list when an associated
suspend blocker is activated.

When the "active" list is empty and no suspend blockers are activated,
the power manager freezes ALL other processes, trusted and untrusted
alike. It then does a big poll() on all the wakeup sources. When the
poll() returns, its output is used to repopulate the "active" list and
processes are unfrozen.

(You can also include some error detection: If a source remains on the
"active" list for too long then something has gone wrong.)

To do all this you don't even need to use cgroups. The existing PM
implementation allows a user process to freeze everything but itself;
that's how swsusp and related programs work.

This is still a big-hammer sort of approach, but it doesn't require any
kernel changes.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: david on
On Sun, 6 Jun 2010, Florian Mickler wrote:

> On Sun, 6 Jun 2010 12:19:08 +0200
> Vitaly Wool <vitalywool(a)gmail.com> wrote:
>
>> 2010/6/6 <david(a)lang.hm>:
>>
>>> as an example (taken from this thread).
>>>
>>> system A needs to wake up to get a battery reading, store it and go back to
>>> sleep, It does so every 10 seconds. But when it does so it only runs the one
>>> process and then goes back to sleep.
>>>
>>> system B has the same need, but wakes up every 10 minutes. but when it does
>>> so it fully wakes up and this allows the mail app to power up the radio,
>>> connect to the Internet and start checking for new mail before oppurtunistic
>>> sleep shuts things down (causing the mail check to fail)
>>>
>>> System A will last considerably longer on a battery than System B.
>>
>> Exactly, thanks for pointing out the specific example :)
>>
>> ~Vitaly
>
> This does not affect suspend_blockers nor does suspend_blockers
> interfere with that.
>
> Suspend_blockers allow the system to suspend ("mem">/sys/power/state
> suspend), when the userspace decides that the device is not in use.
>
> So implementing suspend_blockers support does not impact any
> optimizations done to either system A nor system B.

Actually, it does.

system A is what's being proposed by kernel developers, where the
untrusted stuff is in a different cgroup and what puts the system to sleep
is 'normal' power management. It doesn't sleep as long, but when it wakes
up the untrusted stuff is still frozen, so it doesn't stay awake long, or
do very much.

System B is suspend blockers where you are either awake or asleep, and
when you wake up you wake up fully, but oppertunistic sleep can interrupt
untrusted processes at any time. The system sleeps longer (as fewer things
can wake it), but when it wakes up it's fully awake.

David Lang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/