Messages in this thread | | | Date | Fri, 16 Dec 2005 14:38:47 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation |
| |
On Fri, 16 Dec 2005, David S. Miller wrote: > > Actually, this points out a problem with "compare and swap". The > typical loop is of the form: > > LOAD [MEM], REG1 > OP REG1, X, REG2 > CAS [MEM], REG1, REG2 > > That first LOAD instruction, if it misses in the L2, causes the cache > line to be requested for sharing. Then the CAS instruction will need > to issue another cache coherency transaction to get the cache line > into owned state.
A number of architectures have a "prefetch for write ownership" instruction that you can use for this. Exactly because "ld+cas" should not get a shared line initially.
I though sparc had an ASI to do the same? No?
> (Are there any CPUs that peek forward and look for the CAS > instruction to decide to issue the more appropriate request > for the cache line in Owned state? That would be cool...)
I don't think anybody does, although it wouldn't be impossible. Any OoO processor would _tend_ to have enough visibility that they could see any stores that are "close" (not just a cas) and might be clever enough to modify a memory read to be a read-with-intent-to-write op.
Of course, if it was in memory (as opposed to somebody elses caches), I think most cache protocols will start it up in exclusive state anyway. Same may or may not happen when you have a dirty hit on another CPU that requires a write-back (ie the other CPU would always invalidate on writeback).
It would seem to be the obvious thing to do for better lock performance, and I'd assume that locks are some of the most common cases of real cache interactions, so maybe the shared case only effectively happens if two CPU's are reading at the same time.
Somebody who looks at cache protocol diagrams could check. I'm too lazy.
Linus - 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/
| |