[Intel-gfx] [RFC PATCH 2/2] Fix per client busyness locking

Umesh Nerlige Ramappa umesh.nerlige.ramappa at intel.com
Tue Sep 6 18:29:15 UTC 2022


On Thu, Sep 01, 2022 at 04:55:22PM -0700, Dixit, Ashutosh wrote:
>On Wed, 31 Aug 2022 15:45:49 -0700, Umesh Nerlige Ramappa wrote:
>>
>
>Hi Umesh,
>
>I have updated my RFC patch based on your feedback so we can discuss again.
>
>> On Wed, Aug 31, 2022 at 12:33:55PM -0700, Ashutosh Dixit wrote:
>> > 1. Do all ce->stats updates and reads under guc->timestamp.lock
>>
>> Other than the question about READ_ONCE/WRITE_ONCE, I am not sure I
>> understand what's broken in the locking logic here. Can you please add some
>> description? thanks
>
>Basically ce->stats.runtime.total and ce->stats.active are tied together so
>should be accessed/updated atomically. Also just the update of
>ce->stats.runtime.total (via lrc_update_runtime()) can have multiple
>concurrent writers so even that has to be protected (since that update is
>not atomic).
>
>These was the reason for:
>* Introducing lrc_update_runtime_locked
>* Returning early from intel_context_get_total_runtime_ns otherwise we'll
>  need to introduce the same locking there
>* Enforcing locking in guc_context_update_stats (which was there in your
>  original patch too)
>
>(I think execlists code didn't have this issue because there
>lrc_update_runtime is called from a tasklet (which iirc is like a single
>thread/cpu). I am not sure how 'active' is updated in execlist mode so
>there may or may not be a problem in intel_context_get_total_runtime_ns).
>
>I have another question: what about that GPU vs. GuC race mentioned in the
>comment? What is the sequence of events there between GPU updating the
>timestamp in the context image vs. GuC setting engine_id to -1 (at least
>what is the sequence in which GPU and GuC supposed to do these updates
>though it may not matter to i915 due to scheduling delays)?

With GPU, KMD and GuC running concurrently, after a context is done, 
this is the sequence.

GPU) updates context image (total_runtime)
KMD) reads total_runtime.
KMD) sees engine_id is valid. KMD uses start_time from pphwsp to 
calculate active_time.
KMD) returns total_runtime + active_time (double accounted busyness!!)
GuC) gets ctxt switchout event and sets engine_id and start_time to ~0

This is not rare when running the IGT tests, so the total runtime is 
updated in the query only if engine_id is idle. continued below ...

>
>>
>> > 2. Pin context image before reading
>> > 3. Merge __guc_context_update_clks and guc_context_update_stats into a
>> >   single function
>> > 4. Call lrc_update_runtime() unconditionally in guc_context_update_stats
>> > 5. Seems no need to update ce->stats.active with this approach
>> >
>> > Some of the above steps may not be correct or complete but the idea is to
>> > discuss/improve the original patch.
>> >
>> > Cc: Umesh Nerlige Ramappa <umesh.nerlige.ramappa at intel.com>
>> > Signed-off-by: Ashutosh Dixit <ashutosh.dixit at intel.com>
>> > ---
>> > drivers/gpu/drm/i915/gt/intel_context.c       |  2 +-
>> > drivers/gpu/drm/i915/gt/intel_context_types.h |  2 +-
>> > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 41 ++++++++++---------
>> > 3 files changed, 24 insertions(+), 21 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/gt/intel_context.c b/drivers/gpu/drm/i915/gt/intel_context.c
>> > index e2d70a9fdac0..c004f676de27 100644
>> > --- a/drivers/gpu/drm/i915/gt/intel_context.c
>> > +++ b/drivers/gpu/drm/i915/gt/intel_context.c
>> > @@ -581,7 +581,7 @@ u64 intel_context_get_total_runtime_ns(struct intel_context *ce)
>> >	u64 total, active;
>> >
>> >	if (ce->ops->update_stats)
>> > -		ce->ops->update_stats(ce);
>> > +		return ce->ops->update_stats(ce);
>>
>> This is an improvement that we can add and eventually, we can make this a
>> GuC specific vfunc. Doing so may also remove the COPS_RUNTIME_ACTIVE_TOTAL
>> option that I added to GuC specific context ops.
>
>I went ahead and did this in v2 of the RFC patch.
>
>> >
>> >	total = ce->stats.runtime.total;
>> >	if (ce->ops->flags & COPS_RUNTIME_CYCLES)
>> > diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h b/drivers/gpu/drm/i915/gt/intel_context_types.h
>> > index f7ff4c7d81c7..699435bfff99 100644
>> > --- a/drivers/gpu/drm/i915/gt/intel_context_types.h
>> > +++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
>> > @@ -59,7 +59,7 @@ struct intel_context_ops {
>> >
>> >	void (*sched_disable)(struct intel_context *ce);
>> >
>> > -	void (*update_stats)(struct intel_context *ce);
>> > +	u64 (*update_stats)(struct intel_context *ce);
>> >
>> >	void (*reset)(struct intel_context *ce);
>> >	void (*destroy)(struct kref *kref);
>> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>> > index bee8cf10f749..40d0edaf2e0a 100644
>> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>> > @@ -1376,7 +1376,6 @@ static void __update_guc_busyness_stats(struct intel_guc *guc)
>> >	spin_unlock_irqrestore(&guc->timestamp.lock, flags);
>> > }
>> >
>> > -static void __guc_context_update_clks(struct intel_context *ce);
>> > static void guc_timestamp_ping(struct work_struct *wrk)
>> > {
>> >	struct intel_guc *guc = container_of(wrk, typeof(*guc),
>> > @@ -1401,7 +1400,8 @@ static void guc_timestamp_ping(struct work_struct *wrk)
>> >
>> >	/* adjust context stats for overflow */
>> >	xa_for_each(&guc->context_lookup, index, ce)
>> > -		__guc_context_update_clks(ce);
>> > +		if (ce->ops->update_stats)
>> > +			ce->ops->update_stats(ce);
>>
>> context pinning logic needs to be separated for this (ping) path vs. the
>> query path - intel_context_get_total_runtime_ns().
>
>Done in v2 of RFC patch.
>
>> >
>> >	intel_gt_reset_unlock(gt, srcu);
>> >
>> > @@ -1476,17 +1476,21 @@ void intel_guc_busyness_unpark(struct intel_gt *gt)
>> >			 guc->timestamp.ping_delay);
>> > }
>> >
>> > -static void __guc_context_update_clks(struct intel_context *ce)
>> > +static u64 guc_context_update_stats(struct intel_context *ce)
>> > {
>> >	struct intel_guc *guc = ce_to_guc(ce);
>> >	struct intel_gt *gt = ce->engine->gt;
>> >	u32 *pphwsp, last_switch, engine_id;
>> > -	u64 start_gt_clk, active;
>> >	unsigned long flags;
>> > +	u64 total, active = 0;
>> >	ktime_t unused;
>> >
>> > +	intel_context_pin(ce);
>>
>> intel_context_pin can sleep and we are not allowed to sleep in this path -
>> intel_context_get_total_runtime_ns(), however we can sleep in the ping
>> worker path, so ideally we want to separate it out for the 2 paths.
>
>Do we know which intel_context_get_total_runtime_ns() call is not allowed
>to sleep? E.g. the code path from i915_drm_client_fdinfo() is allowed to
>sleep. As mentioned I have done this is v2 of RFC patch which I think is
>sufficient, but a more complicated scheme (which I think we can avoid for
>now) would be to pin in code paths when sleeping is allowed.
>

Hmm, maybe intel_context_get_total_runtime_ns can sleep, not sure why I 
was assuming that this falls in the perf_pmu path. This is now in the 
drm_fdinfo query path. + Tvrtko.

@Tvrtko, any idea if intel_context_get_total_runtime_ns path can sleep?

>> >	spin_lock_irqsave(&guc->timestamp.lock, flags);
>> >
>> > +	lrc_update_runtime(ce);
>> > +	total = ce->stats.runtime.total;
>>
>> That would get called every second (default intel_gpu_top query internal)
>> for a long running workload. multiply that with all active contexts.
>>
>> For long running contexts and frequenct queries, calling this ^ when a
>> context is active does not add value. I would just call it in the else like
>> before.
>
>I have done this in v2 but are we certain that when a context is active
>it's ce->stats.runtime.total has been updated? Is it updated on each
>context save or only when scheduling is disabled (which would not happen if
>the context is active). That was the reason for my keeping it out of the
>else.

continued here ...

You are right, it's not updated until scheduling is disabled or a query 
falls in the else block. We can run into a case where the 
stats.runtime.total has not yet been updated because the context is 
switching in/out too frequently and the query always lands in the active 
block. In this case busyness values will accumulate the time between 
switch-out to switch-in and eventually drop when ce->stats.runtime.total 
is updated. This is an issue we need to resolve.

I think we should track the previous value of total_runtime. On a query, 
if total_runtime has changed, we should just return that (irrespective 
of whether engine is active or not. Active time should be part of the 
busyness calculations only if total_runtime has not changed (compared to 
previous sample).

>
>> > +
>> >	/*
>> >	 * GPU updates ce->lrc_reg_state[CTX_TIMESTAMP] when context is switched
>> >	 * out, however GuC updates PPHWSP offsets below. Hence KMD (CPU)
>> > @@ -1502,27 +1506,26 @@ static void __guc_context_update_clks(struct intel_context *ce)
>> >	guc_update_pm_timestamp(guc, &unused);
>> >
>> >	if (engine_id != 0xffffffff && last_switch) {
>> > -		start_gt_clk = READ_ONCE(ce->stats.runtime.start_gt_clk);
>> > -		__extend_last_switch(guc, &start_gt_clk, last_switch);
>> > -		active = intel_gt_clock_interval_to_ns(gt, guc->timestamp.gt_stamp - start_gt_clk);
>> > -		WRITE_ONCE(ce->stats.runtime.start_gt_clk, start_gt_clk);
>> > -		WRITE_ONCE(ce->stats.active, active);
>> > -	} else {
>> > -		lrc_update_runtime(ce);
>> > +		__extend_last_switch(guc, &ce->stats.runtime.start_gt_clk, last_switch);
>> > +		active = intel_gt_clock_interval_to_ns(gt,
>> > +			      guc->timestamp.gt_stamp - ce->stats.runtime.start_gt_clk);
>>
>> Makes sense. Earlier it was a rmw, now it's just a write to
>> ce->stats.runtime.start_gt_clk.
>
>It is still a rmw, just that it is not as explicitly seen in the code as
>was the case earlier.
>
>> >	}
>> >
>> >	spin_unlock_irqrestore(&guc->timestamp.lock, flags);
>> > +	intel_context_unpin(ce);
>> > +
>> > +	return total + active;
>>
>> return ce->stats.runtime.total + active;
>>
>> and then drop the local copy of total by bringing back the else{}.
>
>Some changes here in v2, ce->stats.active had to be revived since we need
>to return previously computed value when we cannot pin.

Let's wait for Tvrtko's inputs. If this can sleep, I'd just use the 
original changes you had.

>
>> > }
>> >
>> > -static void guc_context_update_stats(struct intel_context *ce)
>> > +void lrc_update_runtime_locked(struct intel_context *ce)
>> > {
>> > -	if (!intel_context_pin_if_active(ce)) {
>> > -		WRITE_ONCE(ce->stats.runtime.start_gt_clk, 0);
>> > -		WRITE_ONCE(ce->stats.active, 0);
>> > -		return;
>> > -	}
>> > +	struct intel_guc *guc = ce_to_guc(ce);
>> > +	unsigned long flags;
>> >
>> > -	__guc_context_update_clks(ce);
>> > +	intel_context_pin(ce);
>> > +	spin_lock_irqsave(&guc->timestamp.lock, flags);
>> > +	lrc_update_runtime(ce);
>> > +	spin_unlock_irqrestore(&guc->timestamp.lock, flags);
>> >	intel_context_unpin(ce);
>>
>> From where lrc_update_runtime_locked is being called, I would assume that
>> the context is already pinned (until unpin_guc_id is called).
>
>Fixed in v2.
>
>From the other email:
>
>> From your rfc patch, I like
>> - the idea of not touching ce->stats.active
>> - having the update_stats return u64
>> - not doing a rmw for start_gt_clk
>>
>> With those changes, we are only accessing total in ce->stats, so we don't
>> really need a lrc_update_runtime_locked.
>
>Strictly speaking, (as explained above) because the computation of
>ce->stats.runtime.total in lrc_update_runtime is not atomic and there are
>potentially multiple concurrent callers of lrc_update_runtime,
>lrc_update_runtime_locked is needed and I have retained it in v2.
>
>When you say we don't need it, you probably mean that because we are
>dealing with something like busyness, we can tolerate occasional errors in
>busyness if we don't have locking (and we can't verify busyness values
>anyway though I think they are expected to be monotonically
>increasing). But my question is why not keep it simple and retain the
>locking?

The locking you suggested earlier is fine. I think I assumed the 
ce->stats.runtime.total is being updated atomically, but I see your 
point.

Thanks,
Umesh

>
>Thanks.
>--
>Ashutosh
>
>> > }
>> >
>> > @@ -2780,7 +2783,7 @@ static void guc_context_unpin(struct intel_context *ce)
>> > {
>> >	struct intel_guc *guc = ce_to_guc(ce);
>> >
>> > -	lrc_update_runtime(ce);
>> > +	lrc_update_runtime_locked(ce);
>> >	unpin_guc_id(guc, ce);
>> >	lrc_unpin(ce);
>> >
>> > --
>> > 2.34.1
>> >


More information about the Intel-gfx mailing list