From: Daniel Vetter <daniel@ffwll.ch>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
intel-gfx@lists.freedesktop.org,
Paul Menzel <paulepanter@users.sourceforge.net>,
stable@vger.kernel.org
Subject: Re: [PATCH] drm/i915: use hsw rps tuning values everywhere on gen6+
Date: Thu, 16 Aug 2012 00:38:15 +0200 [thread overview]
Message-ID: <20120815223815.GC5533@phenom.ffwll.local> (raw)
In-Reply-To: <1345041394.2976.54.camel@dabdike.int.hansenpartnership.com>
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 <ben@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.
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.
Thanks, Daniel
--
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48
next prev parent reply other threads:[~2012-08-15 22:37 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 [this message]
2012-08-20 18:44 ` Daniel Vetter
[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=20120815223815.GC5533@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=James.Bottomley@HansenPartnership.com \
--cc=daniel.vetter@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.org \
--cc=paulepanter@users.sourceforge.net \
--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