From: Daniel Vetter <daniel@ffwll.ch>
To: Intel Graphics Development <intel-gfx@lists.freedesktop.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>, stable@vger.kernel.org
Subject: Re: [PATCH] drm/i915: use hsw rps tuning values everywhere on gen6+
Date: Mon, 20 Aug 2012 20:44:16 +0200 [thread overview]
Message-ID: <20120820184416.GD5170@phenom.ffwll.local> (raw)
In-Reply-To: <1345020105-5933-1-git-send-email-daniel.vetter@ffwll.ch>
On Wed, Aug 15, 2012 at 10:41:45AM +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.
>
> 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 <ben@bwidawsk.net>
> Cc: stable@vger.kernel.org
> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ok, I've merged this one here, making the commit message a bit more
cautious. Unfortnately we don't seem to have the understanding (nor the
resources to gain it) of the hw to do better than copy&paste what we get
from the hw team :(
-Daniel
--
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48
next prev parent reply other threads:[~2012-08-20 18:43 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-15 8:41 [PATCH] drm/i915: use hsw rps tuning values everywhere on gen6+ Daniel Vetter
2012-08-15 14:05 ` Paul Menzel
[not found] ` <1345041394.2976.54.camel@dabdike.int.hansenpartnership.com>
2012-08-15 22:38 ` Daniel Vetter
2012-08-20 18:44 ` Daniel Vetter [this message]
[not found] <1345222671.3221.1.camel@dabdike.int.hansenpartnership.com>
2012-08-17 20:31 ` Daniel Vetter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120820184416.GD5170@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=daniel.vetter@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox