From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 2 15:14:44 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2C97E37B401 for ; Sat, 2 Aug 2003 15:14:44 -0700 (PDT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C26643FCB for ; Sat, 2 Aug 2003 15:14:43 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.9/8.12.6) with ESMTP id h72MEhVI015450; Sat, 2 Aug 2003 15:14:43 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9/8.12.6/Submit) id h72MEgrE015449; Sat, 2 Aug 2003 15:14:42 -0700 (PDT) Date: Sat, 2 Aug 2003 15:14:42 -0700 (PDT) From: Matthew Dillon Message-Id: <200308022214.h72MEgrE015449@apollo.backplane.com> To: Shawn References: <20030731201227.28952.qmail@neuroflux.com> <1059859111.1532.0.camel@CPE-65-26-140-154.kc.rr.com> cc: freebsd-hackers@freebsd.org Subject: Re: Assembly Syscall Question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Aug 2003 22:14:44 -0000 It's a toss up. Linux's use of registers for syscall args is not a panacea, because many system calls require more then just the basic call-used registers which means the linux userland code has to save and restore those registers on the stack anyway. And we won't even mention syscalls that require more arguments then you have registers for. Oops! I think the ultimate performance solution is to have some explicitly shared memory between kerneland and userland and store the arguments, error code, and return value there. Being a fairly small package of memory multi-threading would not be an issue as each thread would have its own slot. Of course, FreeBSD has other problems as well.. if you look at our syscall entry and exit code it is simply *horrendous* It goes through an indirect jump and it has to check carry for error returns to set the error code. It is a real mess. What I am doing in DragonFly is reimplementing system calls as messages. It turns out that the overhead is not signifcantly greater (and I haven't even tried optimizing the code yet). With the system call as a message the return code and error are stored in the message itself which means that there are *NO* no special cases and, at least for IA32, the kernel messaging interface has just three fixed arguments which fit easily in the call-used registers. I've been able to get rid of proc->p_retval[], a considerable amount of unnecessary proc/thread pointer passing, and the mechanism is flexible enough to support both synchronous and asynchronous operation as well as both single and multi-threaded operation using the same exact code. Additionally, the mechanism can be extended to support chained system calls (i.e. issue several system calls at once), and transactional sequences. Of course, I haven't actually done all of this yet... I have the messaging infrastructure in place and I am working on asynchronizing I/O and timing system calls (e.g. sleep(), read(), write(), select(), etc..), which is going to take a lot of work, but once that is done the sky is the limit. -Matt :On Fri, 2003-08-01 at 02:59, Terry Lambert wrote: :> Personally, I like to look at the Linux register-based passing :> mechanism in the same light that they look at the FreeBSD use :> of the MMU hardware to assist VM, at the cost of increased :> FreeBSD VM system complexity (i.e. they think our VM is too :> convoluted, and we think their system calls are too convoluted). : :Maybe, but they also support a lot of MMU-less architectures, so it may :have made things simpler for them to not depend on MMU. I wonder if NUMA :had any bearing on that as well... : :-- :Shawn