Messages in this thread | | | Subject | Re: [patch] increase spinlock-debug looping timeouts from 1 sec to 1 min | From | Arjan van de Ven <> | Date | Tue, 20 Jun 2006 10:06:06 +0200 |
| |
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/
| |