From: Haakon Bugge <haakon.bugge@oracle.com>
To: John Stultz <jstultz@google.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>, Will Deacon <will@kernel.org>,
Boqun Feng <boqun@kernel.org>, Waiman Long <longman@redhat.com>,
Ingo Molnar <mingo@kernel.org>
Subject: Re: [PATCH 4/4] test-ww_mutex: Retry lock acquisition after timeout if deadlocked
Date: Thu, 9 Jul 2026 16:56:13 +0000 [thread overview]
Message-ID: <400FDB32-AD4B-4252-9711-5EE7ECA77A14@oracle.com> (raw)
In-Reply-To: <CANDhNCopM9dAzn7kwM0wbpkZDGdOtHHRMLAMmbn7+6kXRmAz-A@mail.gmail.com>
> On 8 Jul 2026, at 22:01, John Stultz <jstultz@google.com> wrote:
>
> On Mon, Jun 22, 2026 at 6:48 AM Haakon Bugge <haakon.bugge@oracle.com> wrote:
[snip]
>> <quote>
>> It is worth mentioning that the last patch retries up to 10,000 lock
>> acquisitions after timeout. This value was determined empirically: 10
>> and 100 retries were insufficient on the test systems, while 10,000
>> provided stable results and avoided false negatives.
>> </quote>
>>
>> Shall I add that to the commit message?
>
> That would be great.
>
>>> If the deadlock resolution takes
>>> longer then we expect in time,
>>
>> That is not the case. When we terminate due to timeout, we have no
>> resolution of the deadlock. I view it as there is a probability we run
>> into deadlock, let's say 10%, for each iteration. Now, if we terminate
>> due to timeout - and - we are unlucky and the last iteration
>> deadlocked, we cannot just return -EDEADLK, as that will mark the test
>> as failed. Instead, we retry some more iterations in order to resolve
>> the deadlock.
>
> But with the retry count needing to be set to 10,000 it seems like
> more then just being unlucky on the last iteration, no?
Good observation. Very unlucky may be?
> I'm still a bit wary on this change, but I am very eager to see these
> occasional failures be sorted out, so thank you for your efforts here!
Another way, if the last iteration fails, it to, let's say, double the timeout and continue, but return on the first successful iteration. But, it is the same fix in new wrapping.
Let me add some statistics in a v2, to see if that could ease your caution here.
Thxs, Håkon
prev parent reply other threads:[~2026-07-09 16:56 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-17 12:13 [PATCH 0/4] test-ww_mutex: Miscellaneous fixes Håkon Bugge
2026-06-17 12:13 ` [PATCH 1/4] test-ww_mutex: Fix module cleanup Håkon Bugge
2026-06-18 17:49 ` John Stultz
2026-06-17 12:13 ` [PATCH 2/4] test-ww_mutex: Report errors from stress workers Håkon Bugge
2026-06-18 17:52 ` John Stultz
2026-07-09 0:03 ` John Stultz
2026-07-09 16:51 ` Haakon Bugge
2026-06-17 12:13 ` [PATCH 3/4] test-ww_mutex: Handle transient -EDEADLK in test_cycle_work Håkon Bugge
2026-06-18 19:04 ` John Stultz
2026-06-22 13:21 ` Haakon Bugge
2026-07-08 19:55 ` John Stultz
2026-07-09 17:05 ` Haakon Bugge
2026-06-17 12:13 ` [PATCH 4/4] test-ww_mutex: Retry lock acquisition after timeout if deadlocked Håkon Bugge
2026-06-18 18:55 ` John Stultz
2026-06-22 13:47 ` Haakon Bugge
2026-07-06 9:01 ` Haakon Bugge
2026-07-06 9:02 ` Haakon Bugge
2026-07-08 20:01 ` John Stultz
2026-07-09 16:56 ` Haakon Bugge [this message]
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=400FDB32-AD4B-4252-9711-5EE7ECA77A14@oracle.com \
--to=haakon.bugge@oracle.com \
--cc=boqun@kernel.org \
--cc=jstultz@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=longman@redhat.com \
--cc=mingo@kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=will@kernel.org \
/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®