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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
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