From: Fabricio Akio via B4 Relay <devnull+fabricioakio.gmail.com@kernel.org>
To: Rob Clark <robin.clark@oss.qualcomm.com>,
Sean Paul <sean@poorly.run>,
Konrad Dybcio <konradybcio@kernel.org>,
Akhil P Oommen <akhilpo@oss.qualcomm.com>,
Dmitry Baryshkov <lumag@kernel.org>,
Abhinav Kumar <abhinav.kumar@linux.dev>,
Jessica Zhang <jesszhan0024@gmail.com>,
Marijn Suijten <marijn.suijten@somainline.org>,
David Airlie <airlied@gmail.com>,
Simona Vetter <simona@ffwll.ch>,
Jordan Crouse <jordan@cosmicpenguin.net>
Cc: linux-arm-msm@vger.kernel.org, dri-devel@lists.freedesktop.org,
freedreno@lists.freedesktop.org, linux-kernel@vger.kernel.org,
Fabricio Akio <fabricioakio@gmail.com>
Subject: [PATCH 1/2] drm/msm: Report no GPU time for a submit killed by hangcheck
Date: Sat, 31 Oct 2026 23:32:50 -0300 [thread overview]
Message-ID: <20261031-a5xx-submit-stats-v1-1-16a67ac96edd@gmail.com> (raw)
In-Reply-To: <20261031-a5xx-submit-stats-v1-0-16a67ac96edd@gmail.com>
From: Fabricio Akio <fabricioakio@gmail.com>
recover_worker() advances the fence over the submit it treats as hung
and retires it through retire_submit(), which computes its elapsed time
and cycles from the stats slot the CP writes after the submit's IBs.
That submit may not have written its end stamps, leaving an older
submit's or zero; the subtraction then wraps, and about 3 years of GPU
time is added to the context's fdinfo drm-engine-gpu and reported in
msm_gpu_submit_retired.
Set the end stamps of the submit the fence is advanced over to its
start stamps, so that it reports no time. Do it after the GPU is reset,
when the CP can no longer write the slot.
Fixes: 4241db42e474 ("drm/msm/gpu: Add trace events for tracking GPU submissions")
Signed-off-by: Fabricio Akio <fabricioakio@gmail.com>
---
Charging the time until the failed submit was retired, as panfrost
does, would need the stamps' counter read at recovery, and that
differs by generation: a6xx stamps CP_ALWAYS_ON_CONTEXT while its
get_timestamp() reads another counter, and a2xx/a3xx have none. So
this reports zero.
---
drivers/gpu/drm/msm/msm_gpu.c | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index 0c2c35636251..40d658a63540 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -468,9 +468,11 @@ static void recover_worker(struct kthread_work *work)
struct msm_drm_private *priv = dev->dev_private;
struct msm_gem_submit *submit;
struct msm_ringbuffer *cur_ring = gpu->funcs->active_ring(gpu);
+ volatile struct msm_gpu_submit_stats *stats;
char *comm = NULL, *cmd = NULL;
unsigned int noreclaim_flag;
struct task_struct *task;
+ uint32_t hung_fence = 0;
int i;
mutex_lock(&gpu->lock);
@@ -548,8 +550,10 @@ static void recover_worker(struct kthread_work *work)
* For the current (faulting?) ring/submit advance the fence by
* one more to clear the faulting submit
*/
- if (ring == cur_ring)
+ if (ring == cur_ring) {
ring->memptrs->fence = ++fence;
+ hung_fence = fence;
+ }
msm_update_fence(ring->fctx, fence);
}
@@ -558,6 +562,15 @@ static void recover_worker(struct kthread_work *work)
gpu->funcs->recover(gpu);
+ /*
+ * The submit retired in place of completing may not have written its
+ * end stamps, leaving an older submit's or zero. Now that the GPU is
+ * reset, set them to its start stamps, so that it reports no time.
+ */
+ stats = &cur_ring->memptrs->stats[hung_fence % MSM_GPU_SUBMIT_STATS_COUNT];
+ stats->alwayson_end = stats->alwayson_start;
+ stats->cpcycles_end = stats->cpcycles_start;
+
/* retire completed submits, plus the one that hung: */
retire_submits(gpu);
--
2.56.0
next prev parent reply other threads:[~2026-11-01 2:32 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-01 2:32 [PATCH 0/2] drm/msm: Per-submission GPU time on A5xx Fabricio Akio via B4 Relay
2026-11-01 2:32 ` Fabricio Akio via B4 Relay [this message]
2026-11-01 2:32 ` [PATCH 2/2] drm/msm/a5xx: Record per-submission GPU time and cycles Fabricio Akio via B4 Relay
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=20261031-a5xx-submit-stats-v1-1-16a67ac96edd@gmail.com \
--to=devnull+fabricioakio.gmail.com@kernel.org \
--cc=abhinav.kumar@linux.dev \
--cc=airlied@gmail.com \
--cc=akhilpo@oss.qualcomm.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=fabricioakio@gmail.com \
--cc=freedreno@lists.freedesktop.org \
--cc=jesszhan0024@gmail.com \
--cc=jordan@cosmicpenguin.net \
--cc=konradybcio@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lumag@kernel.org \
--cc=marijn.suijten@somainline.org \
--cc=robin.clark@oss.qualcomm.com \
--cc=sean@poorly.run \
--cc=simona@ffwll.ch \
/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
all inboxes | Powered by JetHome®