On 27.09.2022 09:45, Tvrtko Ursulin wrote:
On 27/09/2022 07:49, Andrzej Hajda wrote:
On 27.09.2022 01:34, Ceraolo Spurio, Daniele wrote:
On 9/26/2022 3:44 PM, Andi Shyti wrote:
Hi Andrzej,
On Mon, Sep 26, 2022 at 11:54:09PM +0200, Andrzej Hajda wrote:
Capturing error state is time consuming (up to 350ms on DG2), so
it should
be avoided if possible. Context reset triggered by context removal
is a
good example.
With this patch multiple igt tests will not timeout and should run
faster.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1551
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3952
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5891
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6268
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6281
Signed-off-by: Andrzej Hajda <andrzej.hajda@xxxxxxxxx>
fine for me:
Reviewed-by: Andi Shyti <andi.shyti@xxxxxxxxxxxxxxx>
Just to be on the safe side, can we also have the ack from any of
the GuC folks? Daniele, John?
Andi
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
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 22ba66e48a9b01..cb58029208afe1 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -4425,7 +4425,8 @@ static void guc_handle_context_reset(struct
intel_guc *guc,
trace_intel_context_reset(ce);
if (likely(!intel_context_is_banned(ce))) {
- capture_error_state(guc, ce);
+ if (!intel_context_is_exiting(ce))
+ capture_error_state(guc, ce);
I am not sure here - if we have a persistent context which caused a
GPU hang I'd expect we'd still want error capture.
What causes the reset in the affected IGTs? Always preemption timeout?
Affected tests performs always context destroy with bb having
IGT_SPIN_NO_PREEMPTION, and "preempt_timeout_ms" set to 50.
So I guess yes.
Regards
Andrzej
guc_context_replay(ce);
You definitely don't want to replay requests of a context that is
going away.
My intention was to just avoid error capture, but that's even better,
only condition change:
- if (likely(!intel_context_is_banned(ce))) {
+ if (likely(intel_context_is_schedulable(ce))) {
Yes that helper was intended to be used for contexts which should not
be scheduled post exit or ban.
Daniele - you say there are some misses in the GuC backend. Should
most, or even all in intel_guc_submission.c be converted to use
intel_context_is_schedulable? My idea indeed was that "ban" should be
a level up from the backends. Backend should only distinguish between
"should I run this or not", and not the reason.
Regards,
Tvrtko
This seems at least in part due to
https://patchwork.freedesktop.org/patch/487531/, where we replaced
the "context_ban" with "context_exiting". There are several places
where we skipped operations if the context was banned (here
included) which are now not covered anymore for exiting contexts.
Maybe we need a new checker function to check both flags in places
where we don't care why the context is being removed (ban vs
exiting), just that it is?
Daniele
} else {
drm_info(&guc_to_gt(guc)->i915->drm,
And maybe degrade above to drm_dbg, to avoid spamming dmesg?
Regards
Andrzej
--
2.34.1
