Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 29 Apr 2001 15:47:48 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 29 Apr 2001 15:47:37 -0400 Received: from [63.95.87.168] ([63.95.87.168]:47879 "HELO xi.linuxpower.cx") by vger.kernel.org with SMTP id ; Sun, 29 Apr 2001 15:47:22 -0400 Date: Sun, 29 Apr 2001 15:47:20 -0400 From: Gregory Maxwell To: Richard Gooch Cc: Ingo Oeser , "David S. Miller" , Jeff Garzik , "H. Peter Anvin" , linux-kernel@vger.kernel.org Subject: Re: X15 alpha release: as fast as TUX but in user space (fwd) Message-ID: <20010429154720.B17155@xi.linuxpower.cx> In-Reply-To: <20010428215301.A1052@gruyere.muc.suse.de> <200104282256.f3SMuRW15999@vindaloo.ras.ucalgary.ca> <9cg7t7$gbt$1@cesium.transmeta.com> <3AEBF782.1911EDD2@mandrakesoft.com> <15083.64180.314190.500961@pizda.ninka.net> <20010429153229.L679@nightmaster.csn.tu-chemnitz.de> <200104291848.f3TIm6821037@vindaloo.ras.ucalgary.ca> <20010429145552.A17155@xi.linuxpower.cx> <200104291902.f3TJ2Dd21232@vindaloo.ras.ucalgary.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.8i In-Reply-To: <200104291902.f3TJ2Dd21232@vindaloo.ras.ucalgary.ca>; from rgooch@ras.ucalgary.ca on Sun, Apr 29, 2001 at 01:02:13PM -0600 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org 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?) - 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/