From owner-freebsd-current@FreeBSD.ORG Thu Apr 26 13:17:08 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 E7C0916A401 for ; Thu, 26 Apr 2007 13:17:08 +0000 (UTC) (envelope-from ssouhlal@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id D4F1613C457 for ; Thu, 26 Apr 2007 13:17:08 +0000 (UTC) (envelope-from ssouhlal@freebsd.org) Received: from [192.168.0.97] (c-76-21-32-5.hsd1.ca.comcast.net [76.21.32.5]) by elvis.mu.org (Postfix) with ESMTP id B5A991A4D98; Thu, 26 Apr 2007 06:17:34 -0700 (PDT) In-Reply-To: <20070426102420.GA819@turion.vk2pj.dyndns.org> References: <20070423113400.GC28587@gw.humppa.dk> <2018ADA6-11D5-48D1-98BD-4397A60E14AF@FreeBSD.org> <20070426102420.GA819@turion.vk2pj.dyndns.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Suleiman Souhlal Date: Thu, 26 Apr 2007 06:15:58 -0700 To: Peter Jeremy X-Mailer: Apple Mail (2.752.3) Cc: 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 13:17:09 -0000 On Apr 26, 2007, at 3:24 AM, Peter Jeremy wrote: > On 2007-Apr-25 01:03:19 -0700, Suleiman Souhlal > wrote: >> 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, and have the kernel choose at boot the most >> efficient method (INT 0x80 or SYSENTER/SYSCALL) based on what the CPU >> supports, while still having binaries that run everywhere. > > That's a nice idea. The only downside I see is that it means the > page would need to be executable. I would prefer not to have > data areas executable - even if they are read-only. Why not? > 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. I have a proof of concept patch that enables the kernel to patch itself at boot to use certain instructions in certain selected places based on the CPUID bits: http://people.freebsd.org/~ssouhlal/testing/ bootpatch-20060527.diff . The patch just prefetches the next element in a list when using TAILQ/STAILQ/etc_FOREACH() (which is pretty useless), using the PREFETCHNTA instruction if the CPU supports SSE2 and PREFETCH otherwise, but it could also be used for potentially more useful things like using *FENCE instructions in atomic_store/load_rel/acq_* () when the CPU supports them, instead of LOCK, on i386.. -- Suleiman