Re: Suggestions on Avoiding syscall Overhead

>IMHO, the main usage of the global readonly page is (apart from  
>faster gettimeofday and similar) is that you can put the syscall  
>entry function in it...

This is unnecessary, though.  Put multiple syscall entry
options in libc and query the kernel once to find out which
one(s) are supported.  That's a lot simpler than mapping a global page.
For that matter, if the alternative syscall mechanisms fail
nicely, just have libc try each one to see which are supported.

> I think that FreeBSD should make more use of CPU-specific coding to
> enhance performance.  Maybe even something along the lines of Solaris
> where linking to libc implicitly links to a CPU-specific .so if it
> exists.

This isn't a bad idea.  It should also be relatively easy to
implement (a minor change to rtld), though rebuilding libc
many times with different compiler options would slow builds
noticably.

An alternative would be to provide a build option
that checks the local processor and optimizes for that, so
that a system build would either be "Generic" (for many systems)
or "Local" (optimized for the local processor).  Then anyone
who wanted better performance could just rebuild the system.

However, first it would be good to see some application-level
benchmarks to see if this really helps.  Sure, a program that
does a billion strcpy() operations in a tight loop might benefit,
but does MySQL run any faster?

Tim Kientzle