public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: "Sun, Daisy" <daisy.sun@intel.com>
Cc: "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH v2] drm/i915/bdw: BDW Software Turbo
Date: Mon, 28 Jul 2014 11:17:37 +0200	[thread overview]
Message-ID: <20140728091737.GZ4747@phenom.ffwll.local> (raw)
In-Reply-To: <53D2FA8F.80708@intel.com>

On Fri, Jul 25, 2014 at 05:47:11PM -0700, Sun, Daisy wrote:
> we have reconsidered good suggestions and evaluated performance and complexity again.
> 
> Timer Constant callback would continuously wake up CPU and entire
> package, results in lower CPU and package C-state and shorter battery life,
> especially for standby time.

If you shut down the timer when idle this shouldn't be a concern at all.
See the idle infrastructure we have and e.g. the retire work handler. We
could even put the software turbo into the retire work handler ...

> execbuf is a good one, and we had taken it into account too. execbuf
> can happen much more frequent than flips. Synchronization and calculation
> overhead were the main reasons that we tried to avoid using too much IA
> resource to benefit GT.

Yeah, running it at each execbuf is going to be too expensive. But with
the regular timer there should be no need to also do this in flips - it
might badly interfere with the missed-flip boosting patches from Chris
even.

> Here's is a revised version of software turbo for BDW, please take a
> look and see if there's any concern.

Doesn't seem to be attached.

> For software turbo, it can be tough to find out a perfect solution
> , may need some trade-off.

Well, but we've made already quite some nice improvments with the boosting
logic. So I think it can be done, but I agree it's not easy.

> Revised design:
> GT busyness will still be calculated when page_flip comes in, then GT frequency
> will be adjusted accordingly. This point stays the same as previous design.
> For the cases no flip will happen(server or background task with no display activity)
> which is a previous concern,  set GT frequency to RP0(no turbo algorithm interfered in this
> case).
> 
> Implementation details:
> 1)  Driver start with RP0 as GT frequency.
> 2)  When the flip comes, do the regular software turbo busyness calculation.
> Also set a timer with 250ms;  3)  If the flip keep coming in time, keep
> turbo algorithm, reset timer;
> 4)  When the timer is fired, set RP frequency to RP0 so that the background task will still be taken
> care of(the RPS boost and idle need to be disabled in this situation).
> 5)If the flip comes again, go to 2).
> 
> To recap,
> For most common cases, GT will run at a desired frequency as a
> result of software turbo algorithm;
> For background workloads or no flip environment, GT will be running at RP0 with
> shorter execution time to extend RC6 and pkg C state residency as long as power
> is concerned.
> 
> I'll start with the implementation if all concerns are ironed out.

Ah, I expected a patch ;-) Usually code diffs are much more efficient
communication as a replacement for when you'd use a whiteboard session
with a colocated team. It doesn't need to run nor even compile, just
speudo-code illustrating the main integration points.

Anyway, see above for my comments: No need to integrate with flips if we
do the timer thing correctly.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

      reply	other threads:[~2014-07-28  9:17 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-10  1:00 [PATCH v2] drm/i915/bdw: BDW Software Turbo Daisy Sun
2014-07-10  8:32 ` Chris Wilson
2014-07-10 18:42   ` Sun, Daisy
2014-07-10 19:07     ` Chris Wilson
2014-07-11  2:39       ` Sun, Daisy
2014-07-11  6:15         ` Chris Wilson
2014-07-14  4:22           ` Sun, Daisy
2014-07-14  6:59             ` Daniel Vetter
2014-07-14  7:03               ` Daniel Vetter
2014-07-15  6:35                 ` Sun, Daisy
2014-07-24 20:28                   ` Jesse Barnes
2014-07-25  7:22                     ` Daniel Vetter
2014-07-25 15:51                       ` Sun, Daisy
2014-07-26  0:47                       ` Sun, Daisy
2014-07-28  9:17                         ` Daniel Vetter [this message]

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=20140728091737.GZ4747@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=daisy.sun@intel.com \
    --cc=intel-gfx@lists.freedesktop.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