lkml.org 
[lkml]   [2010]   [Jan]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC][PATCH 6/8] mm: handle_speculative_fault()
On Tue, Jan 05, 2010 at 10:25:43AM -0800, Linus Torvalds wrote:
>
>
> On Tue, 5 Jan 2010, Christoph Lameter wrote:
> >
> > If the critical section protected by the spinlock is small then the
> > delay will keep the cacheline exclusive until we hit the unlock. This
> > is the case here as far as I can tell.
>
> I hope somebody can time it. Because I think the idle reads on all the
> (unsuccessful) spinlocks will kill it.

But on many systems, it does take some time for the idle reads to make
their way to the CPU that just acquired the lock. My (admittedly dated)
experience is that the CPU acquiring the lock has a few bus clocks
before the cache line containing the lock gets snatched away.

> Think of it this way: under heavy contention, you'll see a lot of people
> waiting for the spinlocks and one of them succeeds at writing it, reading
> the line. So you get an O(n^2) bus traffic access pattern. In contrast,
> with an xadd, you get O(n) behavior - everybody does _one_ acquire-for-
> write bus access.

xadd (and xchg) certainly are nicer where they apply!

> Remember: the critical section is small, but since you're contending on
> the spinlock, that doesn't much _help_. The readers are all hitting the
> lock (and you can try to solve the O(n*2) issue with back-off, but quite
> frankly, anybody who does that has basically already lost - I'm personally
> convinced you should never do lock backoff, and instead look at what you
> did wrong at a higher level instead).

Music to my ears! ;-)

Thanx, Paul


\
 
 \ /
  Last update: 2010-01-05 19:59    [W:0.129 / U:0.136 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site