linux-kernel - [PATCH 5.9 38/75] drm/i915/gt: Limit frequency drop to RPe on parking

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20201210142607.941137005@linuxfoundation.org>
Date:   Thu, 10 Dec 2020 15:27:03 +0100
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     linux-kernel@...r.kernel.org
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        stable@...r.kernel.org, Edward Baker <edward.baker@...el.com>,
        Chris Wilson <chris@...is-wilson.co.uk>,
        Andi Shyti <andi.shyti@...el.com>,
        Lyude Paul <lyude@...hat.com>,
        Rodrigo Vivi <rodrigo.vivi@...el.com>
Subject: [PATCH 5.9 38/75] drm/i915/gt: Limit frequency drop to RPe on parking

From: Chris Wilson <chris@...is-wilson.co.uk>

commit aff76ab795364569b1cac58c1d0bc7df956e3899 upstream.

We treat idling the GT (intel_rps_park) as a downclock event, and reduce
the frequency we intend to restart the GT with. Since the two workloads
are likely related (e.g. a compositor rendering every 16ms), we want to
carry the frequency and load information from across the idling.
However, we do also need to update the frequencies so that workloads
that run for less than 1ms are autotuned by RPS (otherwise we leave
compositors running at max clocks, draining excess power). Conversely,
if we try to run too slowly, the next workload has to run longer. Since
there is a hysteresis in the power graph, below a certain frequency
running a short workload for longer consumes more energy than running it
slightly higher for less time. The exact balance point is unknown
beforehand, but measurements with 30fps media playback indicate that RPe
is a better choice.

Reported-by: Edward Baker <edward.baker@...el.com>
Tested-by: Edward Baker <edward.baker@...el.com>
Fixes: 043cd2d14ede ("drm/i915/gt: Leave rps->cur_freq on unpark")
Signed-off-by: Chris Wilson <chris@...is-wilson.co.uk>
Cc: Edward Baker <edward.baker@...el.com>
Cc: Andi Shyti <andi.shyti@...el.com>
Cc: Lyude Paul <lyude@...hat.com>
Cc: <stable@...r.kernel.org> # v5.8+
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@...el.com>
Reviewed-by: Andi Shyti <andi.shyti@...el.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201124183521.28623-1-chris@chris-wilson.co.uk
(cherry picked from commit f7ed83cc1925f0b8ce2515044d674354035c3af9)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@...el.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>

---
 drivers/gpu/drm/i915/gt/intel_rps.c |    4 ++++
 1 file changed, 4 insertions(+)

--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -882,6 +882,10 @@ void intel_rps_park(struct intel_rps *rp
 		adj = -2;
 	rps->last_adj = adj;
 	rps->cur_freq = max_t(int, rps->cur_freq + adj, rps->min_freq);
+	if (rps->cur_freq < rps->efficient_freq) {
+		rps->cur_freq = rps->efficient_freq;
+		rps->last_adj = 0;
+	}

 	GT_TRACE(rps_to_gt(rps), "park:%x\n", rps->cur_freq);
 }