All of lore.kernel.org
 help / color / mirror / Atom feed
From: Francisco Jerez <currojerez@riseup.net>
To: Mika Kuoppala <mika.kuoppala@linux.intel.com>,
	Chris Wilson <chris@chris-wilson.co.uk>,
	intel-gfx@lists.freedesktop.org
Cc: Eero Tamminen <eero.t.tamminen@intel.com>
Subject: Re: [PATCH 2/3] drm/i915: Do not use iowait while waiting for the GPU
Date: Tue, 31 Jul 2018 12:25:48 -0700	[thread overview]
Message-ID: <87a7q7cimb.fsf@riseup.net> (raw)
In-Reply-To: <87bmana77b.fsf@gaia.fi.intel.com>


[-- Attachment #1.1.1: Type: text/plain, Size: 4214 bytes --]

Mika Kuoppala <mika.kuoppala@linux.intel.com> writes:

> Chris Wilson <chris@chris-wilson.co.uk> writes:
>
>> A recent trend for cpufreq is to boost the CPU frequencies for
>> iowaiters, in particularly to benefit high frequency I/O. We do the same
>> and boost the GPU clocks to try and minimise time spent waiting for the
>> GPU. However, as the igfx and CPU share the same TDP, boosting the CPU
>> frequency will result in the GPU being throttled and its frequency being
>> reduced. Thus declaring iowait negatively impacts on GPU throughput.
>>
>> v2: Both sleeps!
>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107410
>> References: 52ccc4314293 ("cpufreq: intel_pstate: HWP boost performance on IO wakeup")
>
> The commit above has it's own heuristics on when to actual ramp up,
> inspecting the interval of io waits.
>
> Regardless of that, with shared tdp, the waiter should not stand in a
> way.

I've been running some tests with this series (and your previous ones).
I still see statistically significant regressions in latency-sensitive
benchmarks with this series applied:

 qgears2/render-backend=XRender Extension/test-mode=Text: XXX ±0.26% x12 -> XXX ±0.36% x15 d=-0.97% ±0.32% p=0.00%
 lightsmark:                                              XXX ±0.51% x22 -> XXX ±0.49% x20 d=-1.58% ±0.50% p=0.00%
 gputest/triangle:                                        XXX ±0.67% x10 -> XXX ±1.76% x20 d=-1.73% ±1.47% p=0.52%
 synmark/OglMultithread:ĝ                                 XXX ±0.47% x10 -> XXX ±1.06% x20 d=-3.59% ±0.88% p=0.00%

Numbers above are from a partial benchmark run on BXT J3455 -- I'm still
waiting to get the results of a full run though.

Worse, in combination with my intel_pstate branch the effect of this
patch is strictly negative.  There are no improvements because the
cpufreq governor is able to figure out by itself that boosting the
frequency of the CPU under GPU-bound conditions cannot possibly help
(The HWP boost logic could be fixed to do the same thing easily which
would allow us to obtain the best of both worlds on big core).  The
reason for the regressions is that IOWAIT is a useful signal for the
cpufreq governor to provide reduced latency in applications that are
unable to parallelize enough work between CPU and the IO device -- The
upstream governor is just using it rather ineffectively.

> And that it fixes a regression:
>

This patch isn't necessary anymore to fix the regression, there is
another change going in that mitigates the problem [1].  Can we please
keep the IO schedule calls here? (and elsewhere in the atomic commit
code)

[1] https://lkml.org/lkml/2018/7/30/880

> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
>
> On other way around, the atomic commit code on updating
> planes, could potentially benefit of changing to the
> io_schedule_timeout. (and/or adopting c state limits)
>
> -Mika
>
>> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
>> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
>> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
>> Cc: Eero Tamminen <eero.t.tamminen@intel.com>
>> Cc: Francisco Jerez <currojerez@riseup.net>
>> ---
>>  drivers/gpu/drm/i915/i915_request.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c
>> index f3ff8dbe363d..3e48ea87b324 100644
>> --- a/drivers/gpu/drm/i915/i915_request.c
>> +++ b/drivers/gpu/drm/i915/i915_request.c
>> @@ -1376,7 +1376,7 @@ long i915_request_wait(struct i915_request *rq,
>>  			goto complete;
>>  		}
>>  
>> -		timeout = io_schedule_timeout(timeout);
>> +		timeout = schedule_timeout(timeout);
>>  	} while (1);
>>  
>>  	GEM_BUG_ON(!intel_wait_has_seqno(&wait));
>> @@ -1414,7 +1414,7 @@ long i915_request_wait(struct i915_request *rq,
>>  				      wait.seqno - 1))
>>  			qos = wait_dma_qos_add();
>>  
>> -		timeout = io_schedule_timeout(timeout);
>> +		timeout = schedule_timeout(timeout);
>>  
>>  		if (intel_wait_complete(&wait) &&
>>  		    intel_wait_check_request(&wait, rq))
>> -- 
>> 2.18.0

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2018-07-31 19:42 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-30 15:25 Trio of latency sensitive patches Chris Wilson
2018-07-30 15:25 ` [PATCH 1/3] drm/i915: Limit C-states when waiting for the active request Chris Wilson
2018-08-01  9:56   ` Chris Wilson
2018-08-03 10:48   ` Tvrtko Ursulin
2018-08-03 11:07     ` Chris Wilson
2018-08-03 13:00       ` Tvrtko Ursulin
2018-08-03 13:57         ` Chris Wilson
2018-07-30 15:25 ` [PATCH 2/3] drm/i915: Do not use iowait while waiting for the GPU Chris Wilson
2018-07-31 13:03   ` Mika Kuoppala
2018-07-31 19:25     ` Francisco Jerez [this message]
2018-07-30 15:25 ` [PATCH 3/3] drm/i915: Interactive RPS mode Chris Wilson
2018-07-30 15:41 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm/i915: Limit C-states when waiting for the active request Patchwork
2018-07-30 15:43 ` ✗ Fi.CI.SPARSE: " Patchwork
2018-07-30 16:03 ` ✓ Fi.CI.BAT: success " Patchwork
2018-07-30 17:47 ` ✗ Fi.CI.IGT: failure " Patchwork

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=87a7q7cimb.fsf@riseup.net \
    --to=currojerez@riseup.net \
    --cc=chris@chris-wilson.co.uk \
    --cc=eero.t.tamminen@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=mika.kuoppala@linux.intel.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.