From: "Bernatowicz, Marcin" <marcin.bernatowicz@linux.intel.com>
To: "Zbigniew Kempczyński" <zbigniew.kempczynski@intel.com>
Cc: igt-dev@lists.freedesktop.org, adam.miszczak@linux.intel.com,
kamil.konieczny@linux.intel.com, lukasz.laguna@intel.com
Subject: Re: [PATCH i-g-t 1/2] lib/xe/xe_spin: initialize ticks_delta to ~0u
Date: Thu, 30 Jul 2026 12:05:10 +0200 [thread overview]
Message-ID: <a3771498-6f76-4355-98af-d4c1f623d13e@linux.intel.com> (raw)
In-Reply-To: <p5dtghxjmq72gubqeydls5spgmtlonwlb5rdhs2iaapsubxqfr@ucwnjmu3diio>
On 7/29/2026 11:42 AM, Zbigniew Kempczyński wrote:
> On Tue, Jul 28, 2026 at 12:26:58PM +0200, Marcin Bernatowicz wrote:
>> Initialize ticks_delta to ~0u instead of 0. This value does not satisfy
>> the COND_BBE exit condition and prevents false batch termination.
> May you elaborate? Does it mean STORE-DWORD (loop) is not visible in the memory
> before COND_BBE is executed? IIUC with ~0 we could also drop this loop.
The issue is not about the STORE-DWORDs (loop) visibility within a
single batch; that's what the pad is for and that path works fine.
The problem is a cross-iteration potential stale cache read: when the
same BO is re-submitted, COND_BBE can read the ticks_delta value leftover
from the previous batch execution - which is <= ctx_ticks (since that's
the exit condition) - and immediately exit before the new SRM write
propagates.
With ticks_delta = 0 (or any value <= ctx_ticks at prev-iteration exit),
a stale read satisfies COND_BBE.
With ~0u, even a stale read of the sentinel gives 0xFFFFFFFF <=
ctx_ticks -> false -> batch continues safely.
To reproduce: each gem_wsim invocation does 4000 submit/wait cycles on
the same BO (5 engines × 5ms each).
The failure appears only after many outer iterations under sustained load:
i=1; while true; do
echo "Iteration: $i"
gem_wsim -w
"1.RCS.5000.0.0,1.BCS.5000.0.0,1.CCS.5000.0.1,1.VCS.5000.0.0,1.VECS.5000.0.0"
-VV -r 4000 || break
((i++))
done
Typical failure after ~60 outer iterations:
CRITICAL: Failed assertion: w->duration.requested_ticks <=
~w->xe.data->spin.ticks_delta
CRITICAL: error: 96000 > 2 (sometimes 0, 1)
With the sentinel reset before each submission, ran two days without
failure.
--
Marcin
>
> --
> Zbigniew
>
>> Signed-off-by: Marcin Bernatowicz <marcin.bernatowicz@linux.intel.com>
>> Cc: Adam Miszczak <adam.miszczak@linux.intel.com>
>> Cc: Kamil Konieczny <kamil.konieczny@linux.intel.com>
>> Cc: Lukasz Laguna <lukasz.laguna@intel.com>
>> ---
>> lib/xe/xe_spin.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/lib/xe/xe_spin.c b/lib/xe/xe_spin.c
>> index 874310789..331bed1d2 100644
>> --- a/lib/xe/xe_spin.c
>> +++ b/lib/xe/xe_spin.c
>> @@ -60,7 +60,7 @@ void xe_spin_init(struct xe_spin *spin, struct xe_spin_opts *opts)
>> spin->start = 0;
>> spin->end = 0xffffffff;
>> spin->wait_cond = 0;
>> - spin->ticks_delta = 0;
>> + spin->ticks_delta = ~0u;
>>
>> if (opts->ctx_ticks) {
>> /* store start timestamp */
>> --
>> 2.43.0
>>
next prev parent reply other threads:[~2026-07-30 10:06 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-28 10:26 [PATCH i-g-t 0/2] gem_wsim: fix batch premature completion Marcin Bernatowicz
2026-07-28 10:26 ` [PATCH i-g-t 1/2] lib/xe/xe_spin: initialize ticks_delta to ~0u Marcin Bernatowicz
2026-07-29 9:42 ` Zbigniew Kempczyński
2026-07-30 10:05 ` Bernatowicz, Marcin [this message]
2026-07-28 10:26 ` [PATCH i-g-t 2/2] benchmarks/gem_wsim: re-arm ticks_delta before batch submission Marcin Bernatowicz
2026-07-28 11:53 ` ✓ Xe.CI.BAT: success for gem_wsim: fix batch premature completion Patchwork
2026-07-28 12:07 ` ✓ i915.CI.BAT: " Patchwork
2026-07-28 15:18 ` ✓ Xe.CI.FULL: " Patchwork
2026-07-28 15:45 ` ✗ i915.CI.Full: failure " Patchwork
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=a3771498-6f76-4355-98af-d4c1f623d13e@linux.intel.com \
--to=marcin.bernatowicz@linux.intel.com \
--cc=adam.miszczak@linux.intel.com \
--cc=igt-dev@lists.freedesktop.org \
--cc=kamil.konieczny@linux.intel.com \
--cc=lukasz.laguna@intel.com \
--cc=zbigniew.kempczynski@intel.com \
/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