From owner-freebsd-current@FreeBSD.ORG Thu Apr 26 15:53:42 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DD6CF16A400 for ; Thu, 26 Apr 2007 15:53:42 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (h-66-166-149-50.snvacaid.covad.net [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id 8E5F913C45B for ; Thu, 26 Apr 2007 15:53:42 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from [10.0.0.222] (p54.kientzle.com [66.166.149.54]) by kientzle.com (8.12.9/8.12.9) with ESMTP id l3QFrfH7099180; Thu, 26 Apr 2007 08:53:42 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <4630CB05.8090901@freebsd.org> Date: Thu, 26 Apr 2007 08:53:41 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060422 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Jeremy References: <20070423113400.GC28587@gw.humppa.dk> <2018ADA6-11D5-48D1-98BD-4397A60E14AF@FreeBSD.org> <20070426102420.GA819@turion.vk2pj.dyndns.org> In-Reply-To: <20070426102420.GA819@turion.vk2pj.dyndns.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Suleiman Souhlal , current@freebsd.org Subject: Re: Suggestions on Avoiding syscall Overhead X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2007 15:53:43 -0000 >IMHO, the main usage of the global readonly page is (apart from >faster gettimeofday and similar) is that you can put the syscall >entry function in it... This is unnecessary, though. Put multiple syscall entry options in libc and query the kernel once to find out which one(s) are supported. That's a lot simpler than mapping a global page. For that matter, if the alternative syscall mechanisms fail nicely, just have libc try each one to see which are supported. > I think that FreeBSD should make more use of CPU-specific coding to > enhance performance. Maybe even something along the lines of Solaris > where linking to libc implicitly links to a CPU-specific .so if it > exists. This isn't a bad idea. It should also be relatively easy to implement (a minor change to rtld), though rebuilding libc many times with different compiler options would slow builds noticably. An alternative would be to provide a build option that checks the local processor and optimizes for that, so that a system build would either be "Generic" (for many systems) or "Local" (optimized for the local processor). Then anyone who wanted better performance could just rebuild the system. However, first it would be good to see some application-level benchmarks to see if this really helps. Sure, a program that does a billion strcpy() operations in a tight loop might benefit, but does MySQL run any faster? Tim Kientzle