On (Thu) 17 Jul 2014 [11:11:15], Daniel Vetter wrote: > On Thu, Jul 17, 2014 at 02:32:41PM +0530, Amit Shah wrote: > > On (Thu) 17 Jul 2014 [09:35:20], Daniel Vetter wrote: > > > On Wed, Jul 16, 2014 at 9:54 PM, Linus Torvalds > > > <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > > > Sorry for the top post, I'm on the road.. > > > > > > > > In wondering if we couldn't just keep both the old an the new names and have > > > > them both point at the same variable? Remove the description for the old > > > > name, but keep it working? > > > > > > I'm really surprised here ... We have rc6 enabled by default > > > everywhere, and all the additional rc6 levels that users try to enable > > > are known to hard-hang machines. > > > > I haven't had this problem on my hardware (ThinkPad T420s, lspci > > below) for a few kernel versions. I think I added the enable_rc6= > > setting back from the time the deeper states were enabled and then > > reverted for SandyBridge. > > > > Nevertheless, with the current state, RC6p and RC6pp states are not > > used. > > Yeah, on snb they cause crashes and instability and also don't provide > measurable power benefits (afaik). So I recommend you drop that one. Not for me -- there have been no crashes / hangs / lockups as I mentioned. > > > I actually have plans to taint the > > > kernel if you set any of them since I'm fed up with the random crash > > > reports. Same for fbc, even more so or the ppgtt knob. My stance is > > > that if you know about these knobs you _really_ should know the driver > > > to its depths and so also be able to follow module parameter > > > renamings. > > > > I also remember there being bugzillas about power consumption, and > > using this setting was recommended (for Fedora, I think). I know > > a few people are using this setting. > > I know, google is littered with such entries. Unfortunately by the time > google thinks something is important (which usually takes a few months) > it's already badly outdated: i915 graphics developement is charging ahead > at a really brisk pace - we merge a few hundred patches per release for > i915 alone. But for SNB, there's really no "improvement" for the RC6 states, is there? > > > > On Jul 16, 2014 8:34 AM, "Amit Shah" <amit.shah@xxxxxxxxxx> wrote: > > > >> > > > >> This reverts commit 3adee7a7976012a20f1d3b5a529a3c105e29fef1. > > > >> > > > >> After upgrading to v3.15, my laptop's battery started draining quite > > > >> fast. Powertop pointed to the deep RC6 states not being used. The > > > >> kernel param I had put to enable them had stopped working the way it > > > >> used to; so I disagree with the 'not maintaing ABI' part of the param > > > >> name change. > > > >> > > > >> However weird the names may be, they're in active use and changing them > > > >> only causes pain for users. This also isn't advertised (marked > > > >> deprecated, big warning shown, etc.), so just reverting now. > > > >> > > > >> CC: Daniel Vetter <daniel.vetter@xxxxxxxx> > > > >> CC: Jani Nikula <jani.nikula@xxxxxxxxxxxxxxx> > > > >> CC: David Airlie <airlied@xxxxxxxx> > > > >> CC: <stable@xxxxxxxxxxxxxxx> # v3.15+ > > > >> Signed-off-by: Amit Shah <amit.shah@xxxxxxxxxx> > > > > > > Anyway we need to figure out what went wrong here. Please share your > > > exact kernelcmdline and lspci -nn. Also stats for before/after from > > > powertop when idle please. > > > > Powertop stats for idle are a little difficult -- since this is my > > primary laptop. > > Now I'm a bit confused: How have you measured that the lack of rc6p/pp is > the reason for your power consumption regression? > -Daniel What I meant was rebooting in the middle of something is a pain (usually a week or two between trying these things); and also for a fair comparison, the workloads have to be similar for both the powertop ratings. In any case, my daily work doesn't change, and I noticed this immediately upon booting into 3.15. The laptop heats up a bit more, that's the first clue; and the battery doesn't provide as much backup as it used to. Amit _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
