Subject: Re: memsync/cacheflush proposals: status
From: Ignatios Souvatzis <email@example.com>
Date: 02/09/1999 20:35:24
On Tue, Feb 09, 1999 at 09:56:49AM -0800, Eduardo E. Horvath wrote:
> 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
> combination of:
> 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.
Uhm, no. Real CPUs (I've read a lot of PPC documentation in the last year) have
special primitives to build synchronization code... and were not, you could
always create a system call to deal with this.