Re: [patch] increase spinlock-debug looping timeouts from 1 sec to 1 min

[Arjan van de Ven <arjan@infradead.org>]

On Mon, 2006-06-19 at 12:55 -0700, Andrew Morton wrote:

> I get that impression ;) If it takes 1-2 seconds to get this lock then it
> can take five seconds.  a) that's just gross and b) the NMI watchdog will
> nuke the box.
> 
> Why is it taking so long to get the lock?

on a high level, this is a "feature" of unfair read/write locks in
general. Just have enough processors and a lock that can be taken for
read as a result from a userspace action, and BLAM you have this as a
user triggerable condition... which is effectively a DoS security issue.

> What do we do about it?

read/write spinlocks are effectively silly. There is NO scalability
advantage in practice (well, there would be if you have really long hold
times, which you don't for spinlocks, rwsems are obviously different
there). This may sound counter intuitive.... but nowadays the
scalability cost for taking a lock is in the cache miss for bouncing the
cacheline of the lock to your cpu for write. (once this is done the
actual locked cycle tends to be free or near free)

In this cache bounce aspect, read/write spinlocks are no better than
normal spinlocks. In fact, in the ">1 concurrent readers" case, they are
*worse* than normal spinlocks! 

So I'm entirely on Ingo's side with the "we should get rid of rw
spinlocks as much as we can" proposal; they make no sense whatsoever for
scalability, the only reason they are useful is for recursion...

(well there is a border line case with the rare writer in user context
but the normal users for read in irq context, but even there the
scalability is horrible and this should consider rcu or per-cpu data
realistically)



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/