Re: [RFC PATCH 3/3] x86,smp: auto tune spinlock backoff delay factor

From: Rik van Riel
Date: Sat Dec 22 2012 - 09:28:45 EST

On 12/22/2012 12:42 AM, Michel Lespinasse wrote:

However, I have a few concerns about the behavior of this, which I
think deserve more experimentation (I may try helping with it after
new years).

More experimentation is always good. Different hardware
will probably behave differently, etc...

One thing you mentioned in 0/3 is that the best value varies depending
on the number of CPUs contending. This is somewhat surprising to me; I
would have guessed/hoped that the (inc.tail - inc.head) multiplicative
factor would account for that already.

I had hoped the same, but testing things out while
developing the code showed it not to be so.

A larger constant scales to a larger number of CPUs,
while a smaller constant works faster when there are
few CPUs contending on the lock.

The graph attached to patch 0/3 shows this effect.

What I'm getting at is that I would be more confident that the
autotune algorithm will work well in all cases if the value only
depended on the system parameters such as CPU type and frequency,
rather than per-spinlock parameters such as number of waiters and hold

The autotune algorithm adjusts the delay factor so
we access the spinlock, on average, 2.7 times before
we acquire it (the 3.7th time).

This provides scalability by keeping the number of
shared cache line touches constant for each lock

Going for a fixed value, either at compile time or
at boot time, cannot provide such a guarantee.

I feel this review is too high-level to be really helpful, so I'll
stop until I can find time to experiment :)

I am looking forward to test results.

If anyone manages to break the code, I will fix it...

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at