From owner-freebsd-current@FreeBSD.ORG Fri May 7 08:02:39 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 82BE216A4CE; Fri, 7 May 2004 08:02:39 -0700 (PDT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id D1CA643D5E; Fri, 7 May 2004 08:02:38 -0700 (PDT) (envelope-from scottl@freebsd.org) Received: from freebsd.org (junior-wifi.samsco.home [192.168.0.11]) by pooker.samsco.org (8.12.10/8.12.10) with ESMTP id i47F71u6039115; Fri, 7 May 2004 09:07:01 -0600 (MDT) (envelope-from scottl@freebsd.org) Message-ID: <409BA4F4.7020100@freebsd.org> Date: Fri, 07 May 2004 09:02:12 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: freebsd-current@freebsd.org Subject: Re: 4.7 vs 5.2.1 SMP/UP bridging performance X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Fri, 07 May 2004 15:02:39 -0000 Robert Watson wrote: > On Fri, 7 May 2004, Brad Knowles wrote: > > >>At 10:55 PM -0400 2004/05/06, Robert Watson wrote: >> >> >>> On occasion, I've had conversations with Peter Wemm about providing HAL >>> modules with optimized versions of various common routines for specific >>> hardware platforms. However, that would require us to make a trade-off >>> between the performance benefits of inlining and the performance benefits >>> of a HAL module... >> >> I'm confused. Couldn't you just do this sort of stuff as >>conditional macros, which would have both benefits? > > > Well, the goal of introducing HAL modules would be that you don't have to > recompile the kernel in order to perform local hardware-specific > optimization of low level routines. I.e., you could substitute faster > implementations of zeroing, synchronization, certain math routines, etc > based on the CPU discovered at run-time. While you can have switch > statements, etc, it's faster just to relink the kernel to use the better > implementation for the available CPU. However, if you do that, you still > end up with the function call cost, which might well out-weight the > benefits of specialization. > > Robert N M Watson FreeBSD Core Team, TrustedBSD Projects > robert@fledge.watson.org Senior Research Scientist, McAfee Research > It really depends on how you link the HAL module in. Calling indirectly through function pointers is pretty darn slow, and I suspect that the long pipeline of a P4 makes this even worse. Switching to a better instruction might save you 20 cycles, but the indirect call to do it might cost you 30 and that assumes that the branched instruction stream is still in the L1 cache and that twiddling %esp and %ebp gives no pipeline stalls themselves. Even without the indirect jump, all of the housekeeping that goes into making a function call might drown out most benefits. The only way that this might make sense is if you move the abstraction upwards and have it encompass more common code, or do some sort of self-modifying code scheme early in the boot. The alternative might be to have the HAL be a compile-time option like Brad hinted at. Scott