Date:	Thu, 19 Aug 2010 21:58:15 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	david@...g.hm
Cc:	Felipe Contreras <felipe.contreras@...il.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	"Ted Ts'o" <tytso@....edu>, Brian Swetland <swetland@...gle.com>,
	linux-pm@...ts.linux-foundation.org,
	linux-kernel <linux-kernel@...r.kernel.org>, arve@...roid.com,
	mjg59@...f.ucam.org, pavel@....cz, florian@...kler.org,
	rjw@...k.pl, stern@...land.harvard.edu, peterz@...radead.org,
	tglx@...utronix.de, menage@...gle.com, david-b@...bell.net,
	James.Bottomley@...e.de, arjan@...radead.org, swmike@....pp.se,
	galibert@...ox.com, dipankar@...ibm.com
Subject: Re: Attempted summary of suspend-blockers LKML thread, take three

On Thu, Aug 19, 2010 at 04:10:10PM -0700, david@...g.hm wrote:
> On Fri, 13 Aug 2010, Paul E. McKenney wrote:
> 
> >On Thu, Aug 12, 2010 at 08:52:22PM +0300, Felipe Contreras wrote:
> >>On Thu, Aug 12, 2010 at 7:19 PM, Paul E. McKenney
> >><paulmck@...ux.vnet.ibm.com> wrote:
> >>>On Thu, Aug 12, 2010 at 03:17:29AM +0300, Felipe Contreras wrote:
> >>>>>It seems to me that the same social-engineering approaches work in
> >>>>>both cases.
> >>>>
> >>>>Yes, but if dynamic PM works as advertised, you don't need
> >>>>opportunistic suspend.
> >>>
> >>>For dynamic power management to totally eliminate the need for something
> >>>like suspend blockers, you are having to make some brave assumptions.
> >>>Yes, dynamic power management is quite useful, but there is a big
> >>>difference between something being useful and something doing everything
> >>>for everyone.  You have not yet convinced me that dynamic power management
> >>>will make it to the "doing everything for everyone" stage.
> >>
> >>As it has been explained before, there's a sweet-spot of idleness:
> >>http://article.gmane.org/gmane.linux.kernel/995525
> >>http://article.gmane.org/gmane.linux.ports.arm.omap/37982
> >>
> >>Do you agree that there's such a thing, and if so, do you agree that
> >>the benefits of opportunistic suspend are much less once that point is
> >>reached?
> >
> >I agree that there will be a sweet spot of idleness (though I would call
> >it a "point of diminishing returns"), but only if all the applications
> >are power-optimized.  The advantage of opportunistic suspend is instead
> >its tolerance of power-oblivious applications with minimal degradation
> >of battery life.
> 
> sorry for the late response, the last week has been very hectic.
> 
> I just wanted to note that there is already a tool in the kernel to
> deal with this, the timer jitter/fuzz control. This can be set by an
> application for itself, or it can be set by some other process for
> an application (I don't remember the details of all the ways this
> can be set)
> 
> This could be used in a way similar to how userspace wakelocks are
> set today, if the power management process (that holds the wakelock
> and keep sthe screen lit today) thinks the system should be awake,
> let the jitter/fuzz be small, if that process thinks the system
> should probably be asleep, set the jitter/fuzz to a larger value. If
> other things are running anyway, the timers can fire and be serviced
> normally, otherwise the kernel is free to delay the timer going off
> even for badly written processes.

Indeed, Rafael and Alan Stern are working to make pm_qos do what the
Android guys need, which could (very roughly) be thought of as extending
the jitter/fuzz such that it meets Android's requirements.

							Thanx, Paul
--
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