Re: [patch] increase spinlock-debug looping timeouts (write_lockand NMI)

[Nick Piggin]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/