<html>
<head>
<base href="https://bugs.freedesktop.org/">
</head>
<body><span class="vcard"><a class="email" href="mailto:chris@chris-wilson.co.uk" title="Chris Wilson <chris@chris-wilson.co.uk>"> <span class="fn">Chris Wilson</span></a>
</span> changed
<a class="bz_bug_link
bz_status_NEW "
title="NEW - [Kabylake] RPS waitboost regression since v4.20"
href="https://bugs.freedesktop.org/show_bug.cgi?id=109408">bug 109408</a>
<br>
<table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>What</th>
<th>Removed</th>
<th>Added</th>
</tr>
<tr>
<td style="text-align:right;">Status</td>
<td>NEEDINFO
</td>
<td>NEW
</td>
</tr></table>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - [Kabylake] RPS waitboost regression since v4.20"
href="https://bugs.freedesktop.org/show_bug.cgi?id=109408#c8">Comment # 8</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - [Kabylake] RPS waitboost regression since v4.20"
href="https://bugs.freedesktop.org/show_bug.cgi?id=109408">bug 109408</a>
from <span class="vcard"><a class="email" href="mailto:chris@chris-wilson.co.uk" title="Chris Wilson <chris@chris-wilson.co.uk>"> <span class="fn">Chris Wilson</span></a>
</span></b>
<pre>Based on traces provided by Lyude, we can say that in 4.20 the rps downclocking
is much more rapid than in 4.19, and that is due to
commit 0d55babc8392754352f1058866dd4182ae587d11
Author: Chris Wilson <<a href="mailto:chris@chris-wilson.co.uk">chris@chris-wilson.co.uk</a>>
Date: Thu Aug 2 11:06:28 2018 +0100
drm/i915: Drop stray clearing of rps->last_adj
We used to reset last_adj to 0 on crossing a power domain boundary, to
slow down our rate of change. However, commit 60548c554be2 ("drm/i915:
Interactive RPS mode") accidentally caused it to be reset on every
frequency update, nerfing the fast response granted by the slow start
algorithm.
Fixes: 60548c554be2 ("drm/i915: Interactive RPS mode")
Testcase: igt/pm_rps/mix-max-config-loaded
Signed-off-by: Chris Wilson <<a href="mailto:chris@chris-wilson.co.uk">chris@chris-wilson.co.uk</a>>
Cc: Joonas Lahtinen <<a href="mailto:joonas.lahtinen@linux.intel.com">joonas.lahtinen@linux.intel.com</a>>
Reviewed-by: Mika Kuoppala <<a href="mailto:mika.kuoppala@linux.intel.com">mika.kuoppala@linux.intel.com</a>>
Link:
<a href="https://patchwork.freedesktop.org/patch/msgid/20180802100631.31305-1-chris@chris-wilson.co.uk">https://patchwork.freedesktop.org/patch/msgid/20180802100631.31305-1-chris@chris-wilson.co.uk</a>
(Just waiting on Lyude having the opportunity to confirm that.)
What to do? This does mean that the GPU load is too insubstantial to justify
high clocks by itself, but it is required for a smooth UX.
I am thinking along the lines of not using the rapid downlocking within the
HIGH_POWER zone (and not the rapid uplocking within the LOW_POWER zone?), and
with the observation that we seem to stick to the interactive mode that should
be enough to keep us to high clocks.
I dread putting a powermeter on this... We shall have to look at the rapl
figures for a standardised Lyude-test.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the QA Contact for the bug.</li>
<li>You are on the CC list for the bug.</li>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>