On Tue, Jan 8, 2013 at 2:30 PM, Rik van Riel wrote:
> v3: use fixed-point math for the delay calculations, suggested by Michel
> Lespinasse
>
> - if (head == ticket)
> + if (head == ticket) {
> + /*
> +* We overslept, and
On Tue, Jan 8, 2013 at 2:30 PM, Rik van Riel r...@redhat.com wrote:
v3: use fixed-point math for the delay calculations, suggested by Michel
Lespinasse
- if (head == ticket)
+ if (head == ticket) {
+ /*
+* We
On Tue, Jan 08, 2013 at 05:30:29PM -0500, Rik van Riel wrote:
> Many spinlocks are embedded in data structures; having many CPUs
> pounce on the cache line the lock is in will slow down the lock
> holder, and can cause system performance to fall off a cliff.
>
> The paper "Non-scalable locks are
On Tue, Jan 08, 2013 at 05:30:29PM -0500, Rik van Riel wrote:
Many spinlocks are embedded in data structures; having many CPUs
pounce on the cache line the lock is in will slow down the lock
holder, and can cause system performance to fall off a cliff.
The paper Non-scalable locks are
Many spinlocks are embedded in data structures; having many CPUs
pounce on the cache line the lock is in will slow down the lock
holder, and can cause system performance to fall off a cliff.
The paper "Non-scalable locks are dangerous" is a good reference:
Many spinlocks are embedded in data structures; having many CPUs
pounce on the cache line the lock is in will slow down the lock
holder, and can cause system performance to fall off a cliff.
The paper Non-scalable locks are dangerous is a good reference:
On 01/03/2013 12:17 PM, Rik van Riel wrote:
+ if (!(head % 7) && delay < MAX_SPINLOCK_DELAY)
+ delay++;
+
+ loops = delay * waiters_ahead;
I don't like the head % 7 thing. I think using fixed point arithmetic
would be nicer:
if (delay <
On 01/03/2013 12:17 PM, Rik van Riel wrote:
+ if (!(head % 7) delay MAX_SPINLOCK_DELAY)
+ delay++;
+
+ loops = delay * waiters_ahead;
I don't like the head % 7 thing. I think using fixed point arithmetic
would be nicer:
if (delay
On 01/03/2013 07:31 AM, Michel Lespinasse wrote:
I'll see if I can make a more concrete proposal and still keep it
short enough :)
Looking forward to that. I have thought about it some more,
and am still not sure about a better description for the
changelog...
+#define MIN_SPINLOCK_DELAY 1
On Wed, Jan 2, 2013 at 9:23 PM, Rik van Riel wrote:
> Proportional spinlock delay with a high delay factor works well
> when there is lots contention on a lock. Likewise, a smaller
> delay factor works well when a lock is lightly contended.
>
> Making the code auto-tune the delay factor results
On Wed, Jan 2, 2013 at 9:23 PM, Rik van Riel r...@redhat.com wrote:
Proportional spinlock delay with a high delay factor works well
when there is lots contention on a lock. Likewise, a smaller
delay factor works well when a lock is lightly contended.
Making the code auto-tune the delay factor
On 01/03/2013 07:31 AM, Michel Lespinasse wrote:
I'll see if I can make a more concrete proposal and still keep it
short enough :)
Looking forward to that. I have thought about it some more,
and am still not sure about a better description for the
changelog...
+#define MIN_SPINLOCK_DELAY 1
Many spinlocks are embedded in data structures; having many CPUs
pounce on the cache line the lock is in will slow down the lock
holder, and can cause system performance to fall off a cliff.
The paper "Non-scalable locks are dangerous" is a good reference:
Many spinlocks are embedded in data structures; having many CPUs
pounce on the cache line the lock is in will slow down the lock
holder, and can cause system performance to fall off a cliff.
The paper Non-scalable locks are dangerous is a good reference:
14 matches
Mail list logo
