Messages in this thread | | | Date | Wed, 21 Jun 2006 01:16:52 +1000 | From | Nick Piggin <> | Subject | Re: [patch] increase spinlock-debug looping timeouts (write_lock and NMI) |
| |
Arjan van de Ven wrote: >>Taking the lock is going to transiation the cacheline to exclusive. If >>the next locker tries to take the lock, they transfer the cacheline and >>exclusive access and fail. If they have already tried to take the lock >>earlier, they might only request a readonly state, but it still requires >>a cacheline transfer (which is the expensive part). > > > the "which is the expensive part" isn't entirely true on modern hardware > (and for sure not on multicore systems); due to various bus snooping > tricks and other "pass-the-cacheline" tricks this is relatively cheap; > not free obviously but not nearly as expensive as the exclusive part.
Yes, I meant the entire process of getting the cacheline. The cache coherency is the larger part of the cost (except maybe with shared cache multi cores), however you make it sound like getting exclusive access is fundamentally more expensive than getting shared access. (ok, once you *have* shared access, no problems, but *getting* it is still expensive).
With broadcast snooping cache coherency with MESI, the "getting exclusive" shouldn't be hugely more expensive than "getting shared". Either way the owner has to write out the line and cause the requester to retry iff it was dirty. Then, in the former case, the owner should probably mark their line invalid, in the latter, just shared.
With MOESI, both cases will still have to do the broadcast snoop AFAIK.
Not sure about fancier snoop filters or directory protocols. I can't see why getting E would be that much more expensive than getting S in this situation (sure, in situations where lots of entities are also in S, getting an E might require more invalidates to be sent out...).
And either way, spinlocks are still much more costly than rwlocks, because they still have that first exclusive request, who's effectiveness deteriorates under load. That you *also* have these follow on shared accesses (which will need to be invalidated somehow later anyway), doesn't make them better than read locks.
-- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com
- 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/
| |