Re: X15 alpha release: as fast as TUX but in user space (fwd)

[Gregory Maxwell <greg@linuxpower.cx>]

On Sun, Apr 29, 2001 at 01:02:13PM -0600, Richard Gooch wrote:
> Gregory Maxwell writes:
> > On Sun, Apr 29, 2001 at 12:48:06PM -0600, Richard Gooch wrote:
> > > Ingo Oeser writes:
> > > > On Sun, Apr 29, 2001 at 04:27:48AM -0700, David S. Miller wrote:
> > > > > The idea is that the one thing one tends to optimize for new cpus
> > > > > is the memcpy/memset implementation.  What better way to shield
> > > > > libc from having to be updated for new cpus but to put it into
> > > > > the kernel in this magic page?
> > > > 
> > > > Hehe, you have read this MXT patch on linux-mm, too? ;-)
> > > > 
> > > > There we have 10x faster memmove/memcpy/bzero for 1K blocks
> > > > granularity (== alignment is 1K and size is multiple of 1K), that
> > > > is done by the memory controller.
> > > 
> > > This sounds different to me. Using the memory controller is (should
> > > be!) a privileged operation, thus it requires a system call. This is
> > > quite different from code in a magic page, which is excuted entirely
> > > in user-space. The point of the magic page is to avoid the syscall
> > > overhead.
> > 
> > Too bad this is a performance hack, otherwise we could place the
> > privlaged code in the read-only page, allow it to get execute from
> > user space, catch the exception, notice the EIP and let it continue
> > on.
> 
> No need for anything that complicated. We can merge David's user-space
> memcpy code with the memory controller scheme. We need a new syscall
> anyway to access the memory controller, so we may as well just make it
> a simple interface. Then the user-space code may, on some machines,
> contain a test (for alignment) and call to the new syscall.
> 
> The two schemes are independent, and should be treated as such. Just
> as the magic page code can call the new syscall, so could libc.

Would it make sence to have libc use the magic page for all syscalls? Then
on cpus with a fast syscall instruction, the magic page could contain the
needed junk in userspace to use it.

(i.e. that really should be in libc, but we don't want libc to contain all
sorts of CPU specific cruft.. or is there a more general way to accomplish
this?)