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 <b...@bwidawsk.net> > > 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. James -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
