[PATCH v2] drm/i915/slpc: Optmize waitboost for SLPC

[Belgaumkar, Vinay]

On 10/19/2022 4:05 PM, Vinay Belgaumkar wrote:
> Waitboost (when SLPC is enabled) results in a H2G message. This can result
> in thousands of messages during a stress test and fill up an already full
> CTB. There is no need to request for RP0 if GuC is already requesting the
> same.
>
> v2: Add the tracing back, and check requested freq
> in the worker thread (Tvrtko)
>
> Signed-off-by: Vinay Belgaumkar <vinay.belgaumkar at intel.com>
> ---
>   drivers/gpu/drm/i915/gt/intel_rps.c         | 3 +++
>   drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 7 ++++++-
>   2 files changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c b/drivers/gpu/drm/i915/gt/intel_rps.c
> index fc23c562d9b2..18b75cf08d1b 100644
> --- a/drivers/gpu/drm/i915/gt/intel_rps.c
> +++ b/drivers/gpu/drm/i915/gt/intel_rps.c
> @@ -1016,6 +1016,9 @@ void intel_rps_boost(struct i915_request *rq)
>   		if (rps_uses_slpc(rps)) {
>   			slpc = rps_to_slpc(rps);
>   
> +			GT_TRACE(rps_to_gt(rps), "boost fence:%llx:%llx\n",
> +				 rq->fence.context, rq->fence.seqno);
> +
>   			/* Return if old value is non zero */
>   			if (!atomic_fetch_inc(&slpc->num_waiters))

The issue when we move the req freq check into the slpc_work is that we 
are incrementing num_waiters. That will trigger a de-boost and result in 
a H2G. Need to check the req frequency there as well.

Thanks,

Vinay.

>   				schedule_work(&slpc->boost_work);
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
> index b7cdeec44bd3..7ab96221be7e 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
> @@ -227,14 +227,19 @@ static int slpc_force_min_freq(struct intel_guc_slpc *slpc, u32 freq)
>   static void slpc_boost_work(struct work_struct *work)
>   {
>   	struct intel_guc_slpc *slpc = container_of(work, typeof(*slpc), boost_work);
> +	struct intel_rps *rps = &slpc_to_gt(slpc)->rps;
>   	int err;
>   
>   	/*
>   	 * Raise min freq to boost. It's possible that
>   	 * this is greater than current max. But it will
>   	 * certainly be limited by RP0. An error setting
> -	 * the min param is not fatal.
> +	 * the min param is not fatal. No need to boost
> +	 * if we are already requesting it.
>   	 */
> +	if (intel_rps_get_requested_frequency(rps) == slpc->boost_freq)
> +		return;
> +
>   	mutex_lock(&slpc->lock);
>   	if (atomic_read(&slpc->num_waiters)) {
>   		err = slpc_force_min_freq(slpc, slpc->boost_freq);