Re: [PATCH] randomized delay in locking primitives, take 2

On Sun, Jul 31, 2016 at 10:36:12PM +0200, Mateusz Guzik wrote:
> On Sun, Jul 31, 2016 at 07:03:08AM -0700, Adrian Chadd wrote:
> > Also, yeah, the MOD operator in each loop could get spendy on older
> > CPUs (eg my MIPS CPUs, older ARM stuff, etc.) Is it possible to
> > achieve much the same autotuning with pow2 operations instead of
> > divide/mod?
> > 
> 
> The % operation acts a randomizer. It is optional and I'm happy to ifdef
> it based on the architecture. It does seem to be useful at least on
> amd64.
> 
> As a side note, exponential backoff is not used to keep things smaller
> (see above). It is definitely subject to change later.

I asked for removal of the 64bit divide in the backoff precalculation,
because the calculation is relatively intensive on 32bit i386 or arm,
and loop consists of the calculation heating CPU and only then the loop
starts issuing the PAUSE instructions, encoded as cpu_spinwait().

On the other hand, on e.g. MIPS, this is not true. cpu_spinwait() on
MIPS is empty, so the backoff loop consists of heating CPU anyway.
It does not matter if we heat it using divide instruction or branch
instruction.

I do not know is this fixable on MIPS, but it is definitely a bug on
ARM to have empty cpu_spinwait().  It is additionally the bug that ARM
MD code uses cpu_spinwait() in tight loops as well, without providing
an implementation.