Re: [PATCH] drm/i915: Do not use iowait while waiting for the GPU

[Francisco Jerez <currojerez@riseup.net>]

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

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.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107410
> References: 52ccc4314293 ("cpufreq: intel_pstate: HWP boost performance on IO wakeup")

This patch causes up to ~13% performance regressions (with significance
5%) on several latency-sensitive tests on my BXT:

 jxrendermark/rendering-test=Linear Gradient Blend/rendering-size=128x128:     XXX ±35.69% x53 -> XXX ±32.57% x61 d=-13.52% ±31.88% p=2.58%
 jxrendermark/rendering-test=Transformed Blit Bilinear/rendering-size=128x128: XXX ±3.51% x21 ->  XXX ±3.77% x21   d=-12.08% ±3.41% p=0.00%
 gtkperf/gtk-test=GtkComboBox:                                                 XXX ±1.90% x19 ->  XXX ±1.59% x20    d=-4.74% ±1.71% p=0.00%
 x11perf/test=500px Compositing From Pixmap To Window:                         XXX ±2.35% x21 ->  XXX ±1.73% x21    d=-2.69% ±2.04% p=0.01%
 qgears2/render-backend=XRender Extension/test-mode=Text:                      XXX ±0.38% x21 ->  XXX ±0.40% x25    d=-2.20% ±0.38% p=0.00%
 x11perf/test=500px Compositing From Pixmap To Window:                         XXX ±2.78% x53 ->  XXX ±2.27% x61    d=-1.77% ±2.50% p=0.03%

It's unsurprising to see latency-sensitive workloads relying on the
lower latency offered by io_schedule_timeout(), since the CPUFREQ
governor will have substantial downward bias without it, in response to
the intermittent CPU usage pattern of those benchmarks.

We could possibly have the best from both worlds if the CPUFREQ governor
didn't attempt to EPP-boost the CPU frequency on IOWAIT while the system
is heavily IO-bound, since the occurrence of both conditions
simultaneously indicates the CPU workload is also likely to be IO-bound
and its performance will remain unchanged while boosting the CPU
frequency, so it can only pessimize the performance of the system.  This
could be achieved by using the statistic implemented here [1].  I think
the offending patch should probably be reverted for the time being...

[1] https://patchwork.kernel.org/patch/10312259/

> 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 | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c
> index 5c2c93cbab12..7ef7ade12073 100644
> --- a/drivers/gpu/drm/i915/i915_request.c
> +++ b/drivers/gpu/drm/i915/i915_request.c
> @@ -1330,7 +1330,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));
> -- 
> 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