From: Lyude Paul <lyude@redhat.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Cc: Michel Thierry <michel.thierry@intel.com>,
Eero Tamminen <eero.t.tamminen@intel.com>
Subject: Re: [PATCH 13/25] drm/i915: Reduce the RPS shock
Date: Tue, 19 Feb 2019 16:00:08 -0500 [thread overview]
Message-ID: <1863008a6232acfc3965bafcdfff8ff329500c35.camel@redhat.com> (raw)
In-Reply-To: <20190219122215.8941-13-chris@chris-wilson.co.uk>
Should this maybe be CC'd for stable for v4.20? If so I've already got a
working port of this patch that I can send to you (I've been running it on my
laptop for a while now, seems to work fine)
On Tue, 2019-02-19 at 12:22 +0000, Chris Wilson wrote:
> Limit deboosting and boosting to keep ourselves at the extremes
> when in the respective power modes (i.e. slowly decrease frequencies
> while in the HIGH_POWER zone and slowly increase frequencies while
> in the LOW_POWER zone). On idle, we will hit the timeout and drop
> to the next level quickly, and conversely if busy we expect to
> hit a waitboost and rapidly switch into max power.
>
> This should improve the UX experience by keeping the GPU clocks higher
> than they ostensibly should be (based on simple busyness) by switching
> into the INTERACTIVE mode (due to waiting for pageflips) and increasing
> clocks via waitboosting. This will incur some additional power, our
> saving grace should be rc6 and powergating to keep the extra current
> draw in check.
>
> Food for future thought would be deadline scheduling? If we know certain
> contexts (high priority compositors) absolutely must hit the next vblank
> then we can raise the frequencies ahead of time. Part of this is covered
> by per-context frequencies, where userspace is given control over the
> frequency range they want the GPU to execute at (for largely the same
> problem as this, where the workload is very latency sensitive but at the
> EI level appears mostly idle). Indeed, the per-context series does
> extend the modeset boosting to include a frequency range tweak which
> seems applicable to solving this jittery UX behaviour.
>
> Reported-by: Lyude Paul <lyude@redhat.com>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109408
> References: 0d55babc8392 ("drm/i915: Drop stray clearing of rps->last_adj")
> References: 60548c554be2 ("drm/i915: Interactive RPS mode")
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Lyude Paul <lyude@redhat.com>
> Cc: Eero Tamminen <eero.t.tamminen@intel.com>
> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> Cc: Michel Thierry <michel.thierry@intel.com>
>
> Quoting Lyude Paul:
> > Before reverting 0d55babc8392754352f1058866dd4182ae587d11: [4.20]
> >
> > 35 measurements [of gnome-shell animations]
> > Average: 33.65657142857143 FPS
> > FPS observed: 20.8 - 46.87 FPS
> > Percentage under 60 FPS: 100.0%
> > Percentage under 55 FPS: 100.0%
> > Percentage under 50 FPS: 100.0%
> > Percentage under 45 FPS: 97.14285714285714%
> > Percentage under 40 FPS: 97.14285714285714%
> > Percentage under 35 FPS: 45.714285714285715%
> > Percentage under 30 FPS: 11.428571428571429%
> > Percentage under 25 FPS: 2.857142857142857%
> >
> > After reverting: [4.19 behaviour]
> >
> > 30 measurements
> > Average: 49.833666666666666 FPS
> > FPS observed: 33.85 - 60.0 FPS
> > Percentage under 60 FPS: 86.66666666666667%
> > Percentage under 55 FPS: 70.0%
> > Percentage under 50 FPS: 53.333333333333336%
> > Percentage under 45 FPS: 20.0%
> > Percentage under 40 FPS: 6.666666666666667%
> > Percentage under 35 FPS: 6.666666666666667%
> > Percentage under 30 FPS: 0%
> > Percentage under 25 FPS: 0%
> >
> > Patched:
> > 42 measurements
> > Average: 46.05428571428571 FPS
> > FPS observed: 1.82 - 59.98 FPS
> > Percentage under 60 FPS: 88.09523809523809%
> > Percentage under 55 FPS: 61.904761904761905%
> > Percentage under 50 FPS: 45.23809523809524%
> > Percentage under 45 FPS: 35.714285714285715%
> > Percentage under 40 FPS: 33.33333333333333%
> > Percentage under 35 FPS: 19.047619047619047%
> > Percentage under 30 FPS: 7.142857142857142%
> > Percentage under 25 FPS: 4.761904761904762%
>
> Tested-by: Lyude Paul <lyude@redhat.com>
> ---
> drivers/gpu/drm/i915/i915_irq.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c
> b/drivers/gpu/drm/i915/i915_irq.c
> index 92bb32ed27fb..7c7e84e86c6a 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1288,6 +1288,18 @@ static void gen6_pm_rps_work(struct work_struct
> *work)
>
> rps->last_adj = adj;
>
> + /*
> + * Limit deboosting and boosting to keep ourselves at the extremes
> + * when in the respective power modes (i.e. slowly decrease
> frequencies
> + * while in the HIGH_POWER zone and slowly increase frequencies while
> + * in the LOW_POWER zone). On idle, we will hit the timeout and drop
> + * to the next level quickly, and conversely if busy we expect to
> + * hit a waitboost and rapidly switch into max power.
> + */
> + if ((adj < 0 && rps->power.mode == HIGH_POWER) ||
> + (adj > 0 && rps->power.mode == LOW_POWER))
> + rps->last_adj = 0;
> +
> /* sysfs frequency interfaces may have snuck in while servicing the
> * interrupt
> */
--
Cheers,
Lyude Paul
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2019-02-19 21:00 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-19 12:21 [PATCH 01/25] drm/i915: Move verify_wm_state() to heap Chris Wilson
2019-02-19 12:21 ` [PATCH 02/25] drm/i915: Use time based guilty context banning Chris Wilson
2019-02-19 12:21 ` [PATCH 03/25] drm/i915: Prevent user context creation while wedged Chris Wilson
2019-02-19 13:07 ` Mika Kuoppala
2019-02-19 13:11 ` Chris Wilson
2019-02-19 13:31 ` Mika Kuoppala
2019-02-19 13:20 ` Chris Wilson
2019-02-19 12:21 ` [PATCH 04/25] drm/i915: Avoid reset lock in writing fence registers Chris Wilson
2019-02-20 14:55 ` Mika Kuoppala
2019-02-19 12:21 ` [PATCH 05/25] drm/i915: Reorder struct_mutex-vs-reset_lock in i915_gem_fault() Chris Wilson
2019-02-19 12:21 ` [PATCH 06/25] drm/i915: Trim i915_do_reset() to minimum delays Chris Wilson
2019-02-19 12:21 ` [PATCH 07/25] drm/i915: Trim delays for wedging Chris Wilson
2019-02-19 12:48 ` Mika Kuoppala
2019-02-19 12:21 ` [PATCH 08/25] drm/i915/pmu: Always sample an active ringbuffer Chris Wilson
2019-02-22 12:10 ` Mika Kuoppala
2019-02-22 12:17 ` Chris Wilson
2019-02-22 12:31 ` Mika Kuoppala
2019-02-19 12:21 ` [PATCH 09/25] drm/i915: Replace global_seqno with a hangcheck heartbeat seqno Chris Wilson
2019-02-19 12:22 ` [PATCH 10/25] drm/i915: Remove access to global seqno in the HWSP Chris Wilson
2019-02-19 12:22 ` [PATCH 11/25] drm/i915: Remove i915_request.global_seqno Chris Wilson
2019-02-19 12:22 ` [PATCH 12/25] drm/i915/selftests: Exercise resetting during non-user payloads Chris Wilson
2019-02-19 12:22 ` [PATCH 13/25] drm/i915: Reduce the RPS shock Chris Wilson
2019-02-19 21:00 ` Lyude Paul [this message]
2019-02-20 12:05 ` Chris Wilson
2019-02-20 15:14 ` Mika Kuoppala
2019-02-19 12:22 ` [PATCH 14/25] drm/i915/pmu: Use GT parked for estimating RC6 while asleep Chris Wilson
2019-02-19 12:22 ` [PATCH 15/25] drm/i915: Skip scanning for signalers if we are already inflight Chris Wilson
2019-02-19 12:22 ` [PATCH 16/25] drm/i915/execlists: Suppress mere WAIT preemption Chris Wilson
2019-02-19 12:22 ` [PATCH 17/25] drm/i915/execlists: Suppress redundant preemption Chris Wilson
2019-02-19 12:22 ` [PATCH 18/25] drm/i915: Make request allocation caches global Chris Wilson
2019-02-19 12:22 ` [PATCH 19/25] drm/i915: Introduce i915_timeline.mutex Chris Wilson
2019-02-19 12:22 ` [PATCH 20/25] drm/i915: Keep timeline HWSP allocated until idle across the system Chris Wilson
2019-02-19 12:22 ` [PATCH 21/25] drm/i915: Compute the global scheduler caps Chris Wilson
2019-02-19 12:22 ` [PATCH 22/25] drm/i915: Use HW semaphores for inter-engine synchronisation on gen8+ Chris Wilson
2019-02-19 12:22 ` [PATCH 23/25] drm/i915: Prioritise non-busywait semaphore workloads Chris Wilson
2019-02-19 12:22 ` [PATCH 24/25] drm/i915/execlists: Skip direct submission if only lite-restore Chris Wilson
2019-02-19 12:22 ` [PATCH 25/25] drm/i915: Use __ffs() in for_each_priolist for more compact code Chris Wilson
2019-02-19 12:56 ` [PATCH 01/25] drm/i915: Move verify_wm_state() to heap Ville Syrjälä
2019-02-19 13:05 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/25] " Patchwork
2019-02-19 13:15 ` ✗ Fi.CI.SPARSE: " Patchwork
2019-02-19 13:31 ` ✓ Fi.CI.BAT: success " Patchwork
2019-02-19 17:14 ` ✗ Fi.CI.IGT: failure " Patchwork
2019-02-19 17:16 ` Chris Wilson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1863008a6232acfc3965bafcdfff8ff329500c35.camel@redhat.com \
--to=lyude@redhat.com \
--cc=chris@chris-wilson.co.uk \
--cc=eero.t.tamminen@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=michel.thierry@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox