public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: "Dixit, Ashutosh" <ashutosh.dixit@intel.com>
To: "Belgaumkar, Vinay" <vinay.belgaumkar@intel.com>
Cc: "intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [PATCH 2/3] drm/i915/guc/slpc: Add waitboost functionality for SLPC
Date: Mon, 01 Nov 2021 13:28:06 -0700	[thread overview]
Message-ID: <87pmrj39k9.wl-ashutosh.dixit@intel.com> (raw)
In-Reply-To: <20211101043937.35747-3-vinay.belgaumkar@intel.com>

On Sun, 31 Oct 2021 21:39:36 -0700, Belgaumkar, Vinay wrote:
>
> @@ -945,6 +960,17 @@ void intel_rps_boost(struct i915_request *rq)
>	if (!test_and_set_bit(I915_FENCE_FLAG_BOOST, &rq->fence.flags)) {
>		struct intel_rps *rps = &READ_ONCE(rq->engine)->gt->rps;
>
> +		if (rps_uses_slpc(rps)) {
> +			slpc = rps_to_slpc(rps);
> +
> +			/* Return if old value is non zero */
> +			if (atomic_fetch_inc(&slpc->num_waiters))
> +				return;
> +
> +			if (intel_rps_get_requested_frequency(rps) < slpc->boost_freq)

I think this check is not needed because:

a. The waitboost code only changes min_freq. i915 code should not depend on
   how GuC changes requested_freq in response to change in min_freq.

b. What is more worrisome is that when we "de-boost" we set min_freq to
   min_freq_softlimit. If GuC e.g. has a delay in bringing requested_freq
   down and intel_rps_boost() gets called meanwhile we will miss the one
   opportunity we have to boost the freq (when num_waiters goes from 0 to
   1. Asking GuC to boost when actual_freq is already boost_freq is
   harmless in comparison). So to avoid this risk of missing the chance to
   boost I think we should delete this check and replace the code above
   with something like:

                if (rps_uses_slpc(rps)) {
                        struct intel_guc_slpc *slpc = rps_to_slpc(rps);

                        if (slpc->boost_freq <= slpc->min_freq_softlimit)
                                return;

                        if (!atomic_fetch_inc(&slpc->num_waiters))
                                schedule_work(&slpc->boost_work);

                        return;
                }

Note that this check:

                if (slpc->boost_freq <= slpc->min_freq_softlimit)
                                return;

(which is basically a degenerate case in which we don't have to do
anything), can be probably be implemented when boost_freq is set in sysfs,
or may already be encompassed in "val < slpc->min_freq" in
intel_guc_slpc_set_boost_freq() in which case this check can also be
skipped from this function.

> +void intel_guc_slpc_dec_waiters(struct intel_guc_slpc *slpc)
> +{
> +	/* Return min back to the softlimit.
> +	 * This is called during request retire,
> +	 * so we don't need to fail that if the
> +	 * set_param fails.
> +	 */

nit: maybe follow kernel multi-line comment format.

  reply	other threads:[~2021-11-01 20:37 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-01  4:39 [Intel-gfx] [PATCH v2 0/3] drm/i915/guc/slpc: Implement waitboost for SLPC Vinay Belgaumkar
2021-11-01  4:39 ` [Intel-gfx] [PATCH 1/3] drm/i915/guc/slpc: Define and initialize boost frequency Vinay Belgaumkar
2021-11-01 20:26   ` Dixit, Ashutosh
2021-11-02  0:20     ` Belgaumkar, Vinay
2021-11-01  4:39 ` [Intel-gfx] [PATCH 2/3] drm/i915/guc/slpc: Add waitboost functionality for SLPC Vinay Belgaumkar
2021-11-01 20:28   ` Dixit, Ashutosh [this message]
2021-11-02  0:19     ` Belgaumkar, Vinay
2021-11-01  4:39 ` [Intel-gfx] [PATCH 3/3] drm/i915/guc/slpc: Update boost sysfs hooks " Vinay Belgaumkar
2021-11-01 20:28   ` Dixit, Ashutosh
2021-11-04  0:39     ` Dixit, Ashutosh
2021-11-01  5:05 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/guc/slpc: Implement waitboost for SLPC (rev2) Patchwork
2021-11-01  5:37 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2021-11-01  6:53 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2021-11-01 20:24 ` [Intel-gfx] [PATCH v2 0/3] drm/i915/guc/slpc: Implement waitboost for SLPC Dixit, Ashutosh
2021-11-02  0:18   ` Belgaumkar, Vinay
  -- strict thread matches above, loose matches on Subject: below --
2021-11-02  1:26 [Intel-gfx] [PATCH v3 " Vinay Belgaumkar
2021-11-02  1:26 ` [Intel-gfx] [PATCH 2/3] drm/i915/guc/slpc: Add waitboost functionality " Vinay Belgaumkar
2021-11-04  0:23   ` Dixit, Ashutosh
2021-10-20 19:52 [Intel-gfx] [PATCH 0/3] drm/i915/guc/slpc: Implement waitboost " Vinay Belgaumkar
2021-10-20 19:52 ` [Intel-gfx] [PATCH 2/3] drm/i915/guc/slpc: Add waitboost functionality " Vinay Belgaumkar

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=87pmrj39k9.wl-ashutosh.dixit@intel.com \
    --to=ashutosh.dixit@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=vinay.belgaumkar@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