From: "Belgaumkar, Vinay" <vinay.belgaumkar@intel.com>
To: "Dixit, Ashutosh" <ashutosh.dixit@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, 1 Nov 2021 17:19:44 -0700 [thread overview]
Message-ID: <61bcf30a-7d4c-d2ee-11d6-70d9c990ea27@intel.com> (raw)
In-Reply-To: <87pmrj39k9.wl-ashutosh.dixit@intel.com>
On 11/1/2021 1:28 PM, Dixit, Ashutosh wrote:
> 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.
We already have that check in set_boost_freq function. So, just adding
the atomic_fetch_inc check.
>
>> +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.
>
Ok.
Thanks,
Vinay.
next prev parent reply other threads:[~2021-11-02 0:19 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
2021-11-02 0:19 ` Belgaumkar, Vinay [this message]
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=61bcf30a-7d4c-d2ee-11d6-70d9c990ea27@intel.com \
--to=vinay.belgaumkar@intel.com \
--cc=ashutosh.dixit@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
/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