Message-ID: <1317265636.3112.779.camel@work-vm>
Date:	Wed, 28 Sep 2011 20:07:16 -0700
From:	John Stultz <john.stultz@...aro.org>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	lkml <linux-kernel@...r.kernel.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>, arve@...roid.com,
	markgross@...gnar.org, Alan Stern <stern@...land.harvard.edu>,
	amit.kucheria@...aro.org, farrowg@...ibm.com,
	"Dmitry Fink (Palm GBU)" <Dmitry.Fink@...m.com>,
	linux-pm@...ts.linux-foundation.org, khilman@...com,
	Magnus Damm <damm@...nsource.se>, mjg@...hat.com,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 0/6] [RFC] Proposal for optimistic suspend idea.

On Wed, 2011-09-28 at 10:19 +0200, Peter Zijlstra wrote:
> On Tue, 2011-09-27 at 15:56 -0700, John Stultz wrote:
> > But I think once you get away from some theoretical system, containing
> > only properly behaving apps, having some tools in the kernel to enforce
> > a certain type of behavior (and having the kernel's ability to handle
> > more complex cases like importance inheritance) might be helpful. 
> 
> So you want to add something that sends a SIGBUS or similar to an
> application if it gets a wakeup when its not supposed to? That's what
> happens with memory protection, you get killed.

Although that is more reactive then what I'm thinking.

I'm thinking more enforcement on the front end, where instead of
bunching timers around time intervals, we bunch timers around the events
of "important" processes.

So its not applications get wakeups when they aren't supposed to, its
that we don't schedule timer interrupts for their timers, and we don't
schedule them unless the system is "active" running an "important" task
(allowing them to exploit the small idle cycles of the "important" task,
which are likely too short to allow for any deep-idle state to trigger).

Basically we want the system to be in as deep an idle as possible for as
long as possible. Bunching both timers and task execution allows this.
But instead of pushing things out maybe a second, can we stall tasks
for minutes or hours? If we start doing that, we're going to need some
way for tasks to communicate that: "now is a really bad time for you to
freeze me".

So I'm trying to come up with an API that we can use for that issue as
well (since it starts to approximates the suspend case as those forced
idle times grow).

I'll see if I can't start playing with some patches to try to
demonstrate the idea in a non-suspend context.

> And yes, when Arjan did his powertop thing people did go fix up
> everything that made the top.

Yea, the really terrible offenders did improve and I think that was
great! But now how do we deal with the hundreds of normal applications,
that when combined still cause quite a bit of wakeup noise? How do we
really get to minutes of deep idle on a "normal" system?

> It really isn't that hard to fix most of these apps. But the problem
> with Android is that the battery usage thing it has is utterly useless.
> It mostly just tells you wireless or whatnot is sucking power, not what
> app is causing that. (And of course the fact that its all fucking Java
> crap, which I'll refuse to touch anyway).
> 
> This results in people (me) uninstalling everything they installed since
> last it worked well and then cursing this crappy shit for wasting their
> time.

Sure Android has issues, no argument there.

But realize that while part of my motivation is to try to mend the
Android fork, another part is that the need for extreme power efficiency
is not just about phones. I'm trying to find a solution that works for
both on servers with classic linux distros as well as the Android
environment (or better, is demonstratively superior to the wakelocks
solution - fixing all your complaints about your phones battery life!).

So arguments about how Android userland sucks aren't really relevant.

> I really think Android is a pile of privacy violating shit, I can't say
> I actually enjoy using the phone. I'm at a point where I can call with
> it (without it telling google whoem all I know and where I'm at) and
> browse the interwebs and have decided to screw apps, they don't work
> anyway.

I'm sorry my patch doesn't address the privacy concerns of using an
Android (or really any) cell phone. :)

thanks
-john


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

Powered by blists - more mailing lists