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
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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Apr 30 2001 - 21:00:22 EST