From owner-p4-projects@FreeBSD.ORG Fri Jan 25 19:07:22 2008 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id D51C616A476; Fri, 25 Jan 2008 19:07:21 +0000 (UTC) Delivered-To: perforce@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80BA416A418; Fri, 25 Jan 2008 19:07:21 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 43CCB13C46B; Fri, 25 Jan 2008 19:07:21 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.1/8.14.1) with ESMTP id m0PJ6Y0T004887; Fri, 25 Jan 2008 12:06:34 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 25 Jan 2008 12:06:09 -0700 (MST) Message-Id: <20080125.120609.87794284.imp@bsdimp.com> To: grehan@FreeBSD.ORG From: "M. Warner Losh" In-Reply-To: <479A17AC.4070004@freebsd.org> References: <4798C436.6090904@gmail.com> <20080125.100006.-262784007.imp@bsdimp.com> <479A17AC.4070004@freebsd.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: yanegomi@gmail.com, perforce@FreeBSD.ORG, marcel@FreeBSD.ORG Subject: Re: PERFORCE change 133911 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2008 19:07:22 -0000 In message: <479A17AC.4070004@freebsd.org> Peter Grehan writes: : > I'd rather hoped to run the Cisco stuff using EABI, which doesn't need : > fp emulation in the kernel... : : EABI to my mind only helps in ultra-tight embedded environments, which : I don't think exist anymore. 8-byte vs 16-byte stack alignment isn't : going to help anyone. : : And if embedded environments are using a lot of soft-float, they are : running on the wrong type of CPU. Trapping to the kernel should be : infrequent, and it does allow a single ABI for all processor types. I've deployed arm binaries that did to a lot of floating point from time to time, and trapping to the kernel for all of it would have made things a lot slower. These are floating point intensive applications, but in some crude tests that I did I found that the CPU usage jumped from approx 10% for the base system to 25% when I tried go get the floating point emulator in place. The numbers it produced were wrong (I tried to hack the NetBSD binary-only arm one and was only marginally successful), but thought they would be typical of a working implementation. Of course, since I tossed all this work, I can't be sure that I wasn't doing something stupid in the kernel to account for it. So while in theory it shouldn't be a big cost, the application I was just working on it made a huge difference. The applications that are being pushed into these parts are also growing in sophistication. Ours did on the order of 500 floating point operations per second, so it was high enough that the overhead of traps was very noticeable. Anyway, different processor, so the trade offs may be different here. Warner