Re: [PATCH 1/1] kernel/locking: Add mutual exclusion self-test

[Haakon Bugge]

> On 14 Sep 2026, at 23:40, David Laight <david.laight.linux@xxxxxxxxx> wrote:

[snip]

> If you split the 'long counter' into a separate array then it won't
> be in the same cache line as the associated lock.
> That should mean the alignment changes aren't needed.

Yes. I tested that, and the module finds the same "errors". A good
simplification.

> 
> When I mentioned a delay in the RMW for xxx->counter++ I was thinking
> of a few clocks, perhaps something like:
> c = xxx->counter;
> for (auto i = c + 10; i != c; i--)
> 	OPTIMIZER_HIDE_VAR(i);
> OPTIMIZER_HIDE_VAR(i);
> xxx->counter = i + delta;

For the lock-full cases, there are already some instructions to be
executed, the return from mx_acquire(), the call to mx_add(), and
the beginning of mx_release().  So, I am reluctant to add further
delays, unless it can be proven useful for better error detection.

I also looked into your statement that the default number of
locks/counters was too high. I compiled the table below from empirical
testing on a 160-CPU Arm bare-metal system.

For each element count, I ran the test 100 times, with each run
lasting one second. I used the "osq_lock_busted" test which is 
the failing test that is least likely to fail.

   #elements        percent failures
 ===================================
        1024              90
        2048              95
        4096              92
        8192              94
       16384              85
       32768              79
       65536              66

Hence, I yanked the default *up* to 2048.


Thxs, Håkon