From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 3 00:57:33 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 273EB37B401 for ; Sun, 3 Aug 2003 00:57:33 -0700 (PDT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8046B43F93 for ; Sun, 3 Aug 2003 00:57:32 -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 h737vWVI017124; Sun, 3 Aug 2003 00:57:32 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9/8.12.6/Submit) id h737vVV4017123; Sun, 3 Aug 2003 00:57:31 -0700 (PDT) Date: Sun, 3 Aug 2003 00:57:31 -0700 (PDT) From: Matthew Dillon Message-Id: <200308030757.h737vVV4017123@apollo.backplane.com> To: Terry Lambert References: <20030731201227.28952.qmail@neuroflux.com> <200308022214.h72MEgrE015449@apollo.backplane.com> <3F2C59D3.43BBFE7C@mindspring.com> cc: freebsd-hackers@freebsd.org cc: Shawn 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: Sun, 03 Aug 2003 07:57:33 -0000 :You need 8K for this, minimally: 4K that's RO user/RW kernel and :4K that's RW user/RW kernel. You can use it for things like zero :system call getpid/getuid/etc.. : :It's also worth a page doubly mapped, with the second mapping with :the PG_G bit set on it (to make it RO visible to user space at the :sampe place in all programs) to hold the timecounter information; :the current timecounter implementation, with a scad of structures, :is both wasteful and unnecessary, given that pointer assigns are :atomic, so you can implement with only two, which only take a small :part of the page. Doing this, you can use a pointer reference and :a structure assign, and a compare-pointer-afterwards to make a zero :system call gettimeofday() and other calls (consider the benefits :to Apache, SQID, and other programs that have hard "logging with :timestamp" requirements). : :I've also been toying with the idea of putting environp ** in a COW :page, and dealing with changes as a "fixup" operation in the fault :handler (really, environp needs to die, to make way for logical name :tables; it persists because POSIX and SuS demand that it persist). : :So, Matt... how does the modified message based system call :interface fare in a before-and-after with "lmbench"? 8-) 8-). : :-- Terry In regards to using shared memory to optimize certain things, like the time functions... I believe it will be possible to do this in a portable fashion by going through the emulation layer (which is really misnamed... basically the syscall interface layer which will run in userspace but whos code will be managed by the kernel). We don't want the user program having direct knowledge of memory mapped gizmos, but it's perfectly acceptable for the emulation layer to have this knowledge, because the emulation layer will know how to fall back if the gizmo isn't where it's supposed to be (i.e. you boot an older kernel with a newer userland). The messaging code works fairly well so far performance-wise. My original getuid() vs messaging getuid() test on a DELL 2550 (SMP build) comes out: getuid() 0.974s 1088300 loops = 0.895uS/loop getuid() 0.937s 1047500 loops = 0.894uS/loop getuid() 0.971s 1084700 loops = 0.895uS/loop getuid_msg() 1.029s 935400 loops = 1.100uS/loop getuid_msg() 0.970s 881600 loops = 1.100uS/loop getuid_msg() 0.963s 876600 loops = 1.099uS/loop About 200ns slower, and I haven't really tried to optimize any of it yet (and I'm not going to worry about it until a lot more work has been accomplished anyway). -Matt Matthew Dillon