Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx> > Cc: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxxxxxxxx> > Cc: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx> > Cc: Eero Tamminen <eero.t.tamminen@xxxxxxxxx> > Cc: Francisco Jerez <currojerez@xxxxxxxxxx> > --- > 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:
signature.asc
Description: PGP signature
_______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
