[linux-sh:03193] Re: [linuxsh-dev] Re: cache info

On Sun, 21 Mar 2004 08:38:09 +0900 (JST) Kaz Kojima <[email protected]> wrote:

> Paul Mundt <[email protected]> wrote:
> > How important is the information that glibc needs early on in the
> > init process? Is it possible to use a generic definition that works
> > for the worst case and then re-evaluate that once procfs is up?
> 
> I'm not sure how important it is, but anyway it's very likely
> to call it at the initialization itself.
> It's used in sysconf function and although such fallback with
> procfs would be possible, other architectures return the value
> which is considered as safe or simply return a failure for the
> case in which cpu registers give not enough info.  I'll use
> a such easy fallback as the last resort if our new syscall
> returns ENOSYS.

I think you're right, if the information is only needed for sysconf()
then the overhead of a system call is probably fine. It might be
worth while caching the information in user space just to be on the
safe side though.

Slightly off topic, but I've recently been having a discussion with a
colleague about the nest way to support cache flushing for user
applications which need to do a lot of it. The two which spring to
mind are gcc trampolines and JIT compilers.

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.

Whether this is best implemented as a device which has be be mmap'ed,
or something the kernel always does before a process starts running, we
never came to a conclusion, but either should work.

> > 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.

> Thanks.  I'll take a look at that stuff.

If anyone is interested I have the glibc end of this available as well.

Stuart

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (SunOS)

iD8DBQFAXvpv61BlSKQGbXkRAm43AJ0VFecmO+BbpgM9RYbToi4gBNL2kgCdG4CV
kKULF3EzH2I197cU6HmmfQA=
=9Rpl
-----END PGP SIGNATURE-----