On Thu, 2012-08-16 at 00:38 +0200, Daniel Vetter wrote: > On Wed, Aug 15, 2012 at 03:36:34PM +0100, James Bottomley wrote: > > On Wed, 2012-08-15 at 16:05 +0200, Paul Menzel wrote: > > > Am Mittwoch, den 15.08.2012, 10:41 +0200 schrieb Daniel Vetter: > > > > between 3.5 and 3.6 in a merge commit! So rc6 behaviour with the > > > > current setting seems to be highly timing dependent and not robust > > > > at all. > > > > - The behaviour James reported wrt semaphores seems to be a freak > > > > timing thing that only happens on his specific machine, confirming > > > > that enabling semaphores shouldn't reduce rc6 residency. > > > > > > > > Now furthermore the Google ChromeOS guys reported [2] a while ago that > > > > at least on some machines a simply a blinking cursor can keep the gpu > > > > turbo at the highest frequency. This is because the current rps limits > > > > used on snb/ivb are highly asymmetric. > > > > > > > > On the theory that gpu turbo and rc6 tuning values are related, we've > > > > tried whether the much saner looking (since much less asymmetric) rps > > > > tuning values used for hsw would also help entering rc6 more robustly. > > > > > > > > And it seems to work. > > > > > > > > Reference[1]: > > > > http://lists.freedesktop.org/archives/dri-devel/2012-July/025675.html > > > > Reference[2]: > > > > http://lists.freedesktop.org/archives/intel-gfx/2012-July/018692.html > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=53393 > > > > Tested-by: Ben Widawsky <[email protected]> > > > > > > Did James already confirm, that this fixes his problem? > > > > Well, no ... I think no-one cc'd me on anything after the initial bug > > report, but the patch won't apply to 3.5, so cc stable isn't really > > going to work ... it will need backporting. > > > > I can test either the backport or 3.6-rc1 with the patch if there's > > interest. > > Sorry, the cc: you got lost, testing feedback highly welcome. The ChromeOS > guys just reported back that for them fully symmetric values actually lead > to the least power consumption for light gpu loads (which these are not > yet), so maybe we need to tune things some more even.
I think so. It's closer but still not optimal: with this patch and semaphores enabled on 3.6-rc2 I get down to ~8.9W. With semaphores disabled on the same kernel I get to ~7.2W (so 3.6-rc2 is missing ~0.7W on something else as well). James -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
