[Bug 109408] [Kabylake] RPS waitboost regression since v4.20

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=109408

Chris Wilson <chris at chris-wilson.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEEDINFO                    |NEW

--- Comment #8 from Chris Wilson <chris at chris-wilson.co.uk> ---
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 <chris at chris-wilson.co.uk>
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 <chris at chris-wilson.co.uk>
    Cc: Joonas Lahtinen <joonas.lahtinen at linux.intel.com>
    Reviewed-by: Mika Kuoppala <mika.kuoppala at linux.intel.com>
    Link:
https://patchwork.freedesktop.org/patch/msgid/20180802100631.31305-1-chris@chris-wilson.co.uk

(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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are on the CC list for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20190215/c36c37dc/attachment.html>