From: Rafael J. Wysocki on
On Sunday 06 June 2010, Brian Swetland wrote:
> On Sat, Jun 5, 2010 at 3:23 PM, Arjan van de Ven <arjan(a)infradead.org> wrote:
> >>
> >> We clearly have different standards for what we consider good. We
> >> measure time suspended in minutes or hours, not seconds, and waking up
> >> every second or two causes a noticeable decrease in battery life on
> >> the hardware we have today.
> >
> > I guess I'm spoiled working with (unreleased) hardware that knows how
> > to power gate ;-)
>
> I'm continually surprised by answers like this. We run on hardware
> that power gates very aggressively and draws in the neighborhood of
> 1-2mA at the battery when in the lowest state (3-5mA while the radio
> is connected to the network and paging). Waking up out of that lowest
> state and executing code every few seconds or (worse) several times a
> second) will raise your average power consumption. Being able to stay
> parked at the very bottom for minutes or hours at a time when nothing
> "interesting" is happening is very useful and can have a significant
> impact on overall battery life.

Yes, and if you look at the approach I proposed in this very thread
(http://lkml.org/lkml/2010/6/4/368), it goes exactly in this direction.

And I think it is superior to the opportunistic suspend framework you have
right now, because, for example, it doesn't require you to carry out full
system resume and full system suspend every once a while to check battery
status.

And guess what, suspending and resuming the whole system actually uses energy.

Rafael
--
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: Rafael J. Wysocki on
On Sunday 06 June 2010, Arve Hj�nnev�g wrote:
> 2010/6/5 Rafael J. Wysocki <rjw(a)sisk.pl>:
> > On Saturday 05 June 2010, Arve Hj�nnev�g wrote:
> >> 2010/6/4 Matt Helsley <matthltc(a)us.ibm.com>:
> >> > On Fri, Jun 04, 2010 at 05:39:17PM -0700, Arve Hj�nnev�g wrote:
> >> >> On Fri, Jun 4, 2010 at 5:05 PM, Thomas Gleixner <tglx(a)linutronix.de> wrote:
> >> >> > On Sat, 5 Jun 2010, Rafael J. Wysocki wrote:
> >> >
> >> > <snip>
> >> >
> >> >>
> >> >> > With the cgroup freezer you can "suspend" them right away and
> >> >> > just keep the trusted background task(s) alive which allows us to
> >> >> > go into deeper idle states instead of letting the crapplications
> >> >> > run unconfined until the download finished and the suspend
> >> >> > blocker goes away.
> >> >> >
> >> >>
> >> >> Yes this would be better, but I want it in addition to suspend, not
> >> >> instead of it. It is also unclear if our user-space code could easily
> >> >> make use of it since our trusted code calls into untrusted code.
> >> >>
> >> >
> >> > Perhaps I'm misunderstanding, but suspend and the cgroup freezer
> >> > interoperate well today -- you don't have to choose one or the other.
> >> > If you've discovered otherwise I'd consider it a bug and would like to
> >> > hear more about it.
> >> >
> >>
> >> I'm not aware of any bug with combining both, but we cannot use
> >> suspend at all without suspend blockers in the kernel (since wakeup
> >> events may be ignored)
> >
> > The more I think of it, the more it appears to me that the problem of
> > lost wakeup events can actually be solved without suspend blockers.
> > I'll send a bunch of patches to address this issue, probably tomorrow.
> >
>
> I know of two ways to prevent lost wakeup events. Reset a timeout
> every time you receive a wakeup event or prevents suspend until you
> know the event has been fully processed. Does your solution fall onto
> one of these two categories, or do you have a third way?

Basically, it involves two mechanisms, detection of wakeup events occuring
right before suspend is started and aborting suspend if wakeup events occur
in the middle of it.

> >> and I don't know how we can safely freeze
> >> cgroups without funneling all potential wakeup events through a
> >> process that never gets frozen.
> >
> > If your untrusted apps get called by the trusted ones, they aren't really
> > untrusted in the first place.
> >
> That is not a correct statement. A trusted apps can call into an
> untrusted app, it just has to validate the response and handle not
> getting a response at all. There are also different levels of trust. I
> may have trusted an app to provide a contact pictures, but not trusted
> it to block suspend. When the phone rings the app will be called to
> provide the picture for the incoming call dialog, but if it is frozen
> at this point the more trusted app that handles the incoming phone
> call will not be able to get the picture.

It will be able to do that if it causes the frozen part of user space to be
thawed.

I think you have this problem already, though, because you use full system
suspend and all of your apps are frozen by it. So, to handle the situation you
describe above, you need to carry out full system resume that will thaw the
tasks for you. I don't see any fundamental difference betwee the two cases.

> > From what you're saying it follows that you're not really willing to accept
> > any solution different to your suspend blockers. Is that really the case?
> >
> I don't think that is a fair way to put it. We need to support our
> user-space framework and I have not seen an alternative solution that
> clearly will work (other than replacing suspend_blockers with pm_qos
> constraints that do the same thing).

Then think again of the approach I proposed and explain to me why it won't
work, because I haven't seen any convincing argument on that yet.

Rafael
--
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: Arjan van de Ven on
On Sat, 5 Jun 2010 15:39:44 -0700
Arve Hjønnevåg <arve(a)android.com> wrote:

> >
> > For example if the Adobe Flash player puts a timer every 10
> > milliseconds (yes it does that), and you give it a 3.99 seconds
> > range, it will fire its timers every 4 seconds.... unless other
> > activity happens independently, at which point it'll align with
> > that instead.
> >
>
> If you do that what you are delivering is nowhere close to what the
> app asked for.

yeah it feels a little bit suspended

> You don't need range timers for this, you could just as
> well add 4 seconds to all normal timers.

... with the difference that with range timers, you naturally align with
other activity, so if there's system level activity, the AVERAGE service
the app gets is better by a LOT than just adding 4 seconds always.

but you knew that.... just doesn't help your case.



--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
--
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: Rafael J. Wysocki on
On Sunday 06 June 2010, Arve Hj�nnev�g wrote:
> 2010/6/5 Thomas Gleixner <tglx(a)linutronix.de>:
> > On Sat, 5 Jun 2010, Arve Hj�nnev�g wrote:
> >> 2010/6/5 Thomas Gleixner <tglx(a)linutronix.de>:
> >> > B1;2005;0cOn Fri, 4 Jun 2010, Arve Hj�nnev�g wrote:
....
> > So taking your example:
> >
> > Event happens and gets delivered to the framework
> >
> > framework selects A because it is in the foreground
> >
> > if (A is frozen)
> > unfreeze(A)
> >
> > deliver_event_to(A)
> >
> > It's that simple.
> >
>
> That is too simple. You also have to prevent A from being frozen while
> it is processing the event or the result would be the same as if it
> was frozen beforehand.

Well, the freezing of the "untrusted" part of user space needs to be triggered
somehow in the first place. Whatever mechanism is used for that, there should
be a way to tell it to not to freeze the "untrusted" part of user space for a
while. Yes, it is similar to wakelocks, but I think it can be implemented
entirely in user space.

So, in general, the "trusted" app that needs an "untrusted" one to handle stuff
will take a "freeze lock" to prevent the power manager from freezing the
"untrusted" part of user space (that will also cause it to thaw these tasks if
they are frozen at the moment) and will release the "freeze lock" when it's
done with its job. You can use timeouts and whatever you like with that and
the kernel doesn't have to participate in that (except for carrying out the
low-level freezing and thawing of the "untrusted" tasks at the power manager's
request).

Rafael
--
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: Thomas Gleixner on
On Sat, 5 Jun 2010, Arjan van de Ven wrote:

> On Sat, 5 Jun 2010 15:26:36 -0700
> Brian Swetland <swetland(a)google.com> wrote:
>
> >
> > I'm continually surprised by answers like this. We run on hardware
> > that power gates very aggressively and draws in the neighborhood of
> > 1-2mA at the battery when in the lowest state (3-5mA while the radio
> > is connected to the network and paging). Waking up out of that lowest
> > state and executing code every few seconds or (worse) several times a
> > second) will raise your average power consumption. Being able to stay
> > parked at the very bottom for minutes or hours at a time when nothing
> > "interesting" is happening is very useful and can have a significant
> > impact on overall battery life.
>
> It's relatively simple math.
>
> If you wake up for a burst of work, you burn power at the higher level
> P1 (versus the lower power level P2), for, lets say an average time T,
> with a relatively small T (few milliseconds at most).
>
> If you wake up X times per second (with X being a fractional number, so
> can be smaller than 1) the extra power consumption factor is
>
> X * T * P1
> -------------------------------
> X * T * P1 + (1.0 - X * T) * P2
>
> if you draw a graph of this, for real values of P and T, there's a real
> point where you hit diminishing returns.
>
> if say T is 5 milliseconds (that's a high amount), and X is 1
> wakeup/second, then there's already a 200:1 ratio in time an power.
>
> If X goes to once every 10 seconds (not unreasonable, especially since
> any real device will pull email and stuff in the backgroudn), you have
> 2000:1 time and power ratios...
>
> Unless your "on" power is insane high (and hopefully it's not, since
> you're not turning on the whole device obviously, you do selective
> power and clock gating)... that "divide by 200 or 2000" makes the whole
> problem go away.. in the "seconds" range for really low power devices.
> Not in "hours" range.

That's the whole problem. Suspend blockers are a binary all on/off
approach so you waste power just to get the thing back to
"suspend". They unleash the world and some more just to put it back
into oblivion with brute force.

Thanks,

tglx
--
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/