Re: Re: cache info

On Mon, Mar 22, 2004 at 02:38:34PM +0000, Stuart MENEFY wrote:
> Ideally we would like to have a solution which allows the same binary
> to be run on parts with different cache architectures, but results in
> 'optimal' flushing.
> 
> The best solution we could come up with was, what is in effect, a
> vsyscall.  This allows the kernel to map different implementations of
> the code into user space based on which cache architecture it has
> detected. This is especially useful for the implementations of I-cache
> flushing where the flush involves executing code placed at specified
> alignments in virtual memory so that fetching the code causes other
> cache lines at the same alignment to be evicted. In this case you
> can map the same physical page multiple times into virtual space to
> have the desired effect.
> 
This definitely sounds like something a vsyscall would be well suited for.

> > > If all you need the data for is flushing, 2.4 already has a
> > > sys_cacheflush on sh (it uses the sys_modify_ldt number, since no
> > > one other than x86 uses it). I haven't added this to 2.6 as of yet
> > > though, and it really should be under its own number. In this event,
> > > sys_cacheflush() will already do the right thing, depending on what
> > > op you hand it (see arch/sh/kernel/sys_sh.c in linux-2_4-branch).
> 
> I used this syscall number because that is what m68k uses.
> 
Ah, ok. That should be fine then.

> > Thanks.  I'll take a look at that stuff.
> 
> If anyone is interested I have the glibc end of this available as well.
> 
I'd certainly be interested, this would definitely make testing easier.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQFAXv7r1K+teJFxZ9wRAhGqAJ4o3Lb5YnDGMAib6MZnx0NWT4JVIwCdGNbC
cEHzjtizKLs63RRWffCdeU8=
=aTF+
-----END PGP SIGNATURE-----