On Fri, 2012-08-17 at 22:31 +0200, Daniel Vetter wrote: > James Bottomley reported [1] a massive power regression, due to the > enabling of semaphores by default in 3.5. A workaround for him is to > again disable semaphores. And indeed, his system has a very hard time > to entre rc6 with semaphores enabled. > > Ben Widawsky run around with a kill-a-watt a lot and noticed: > - There are indeed a few rare systems that seem to have a hard time > entering rc6 when desktop-idle. > - One machine, The Indestructible Toshiba regressed in this behaviour > 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. > > v2: Testing on James Bottemly's funky machine
It's a lenovo X220i ... they're actually pretty common sandybridge core i3 systems. There's nothing really "funky" about them; I'd expect all core i3 systems to behave similarly. > indicates that the > Haswell values are not aggressive enough. And testing from the Google > ChromeOS team indicates that we actually want symmetric values for the > most power savings. So let's try that. This one idles at 10.2W so it's 1.3W worse than the previous patch. 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
