Subject: Re: memsync/cacheflush proposals: status
To: Ignatios Souvatzis <email@example.com>
From: Eduardo E. Horvath <firstname.lastname@example.org>
Date: 02/09/1999 09:56:49
On Tue, 9 Feb 1999, Ignatios Souvatzis wrote:
> - Some people said the MIPS ABI for the cache synchronization provides
> enough functionality, and 3rd-party programs (that need it) are likely to
> know how to use it, so we should not invent a new interface. (Jason Thorpe
> expressed this earlier on this list).
> [[I feel this is a valid argument. Additionally whatever I wanted to do with
> this work can be done with the MIPS ABI.
>From what I know about the MIPS ABI I do not feel that it is sufficient
to handle all possible cache/CPU architectures. You can have any
physical or virtual
split or unified
writeback or write through
snoopy or not snoopy
Uni-processor or MP
And with multiple cache levels you can have different combinations at each
level. Let's take a nasty example of a non-snoopy split virtual
write-back cache on an MP system, which is probably the nastiest of the
When generating new JIT code you need to a way to do I$/D$
synchronization. You need to communicate this to all the other CPUs to have them
invalidate their D$ *and* I$ also.
When spinning on a lock the CPU doing the spinning needs to invalidate its
D$, and the CPU who grabs/releases the lock needs to force the store of
the lock through its D$ and store buffers to RAM.
Then things start geting even more complicated if the architecture has a
relaxed memory model where loads and stores can be re-ordered with
respect to each other and pass each other such as Alpha or SPARC.
Eduardo Horvath email@example.com
"I need to find a pithy new quote." -- me