From owner-freebsd-alpha Wed Nov 13 13:41:38 2002 Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0857037B404 for ; Wed, 13 Nov 2002 13:41:37 -0800 (PST) Received: from mail.speakeasy.net (mail11.speakeasy.net [216.254.0.211]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2CF6D43E8A for ; Wed, 13 Nov 2002 13:41:31 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 3486 invoked from network); 13 Nov 2002 21:41:38 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail11.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 13 Nov 2002 21:41:38 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.6/8.12.6) with ESMTP id gADLfS2D009383; Wed, 13 Nov 2002 16:41:29 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20021113202636.GA23652@gsmx07.alcatel.com.au> Date: Wed, 13 Nov 2002 16:41:31 -0500 (EST) From: John Baldwin To: Peter Jeremy Subject: Re: cvs commit: src/sys/conf files files.i386 files.pc98 Cc: alpha@FreeBSD.ORG Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 13-Nov-2002 Peter Jeremy wrote: > On 2002-Nov-08 17:55:20 -0500, John Baldwin wrote: >>Even with all this we still have a problem. :) The problem is that >>the kernel is too big (well, .text is too big) for it to link with >>our current atomic operation implementation. The problem is that in >>order to optimize for the common case, our atomic operations branch >>to a branch in the .text3 section in the failure case. We branch the >>way we do to take advantage of branch prediction on the alpha. However, >>the LINT kernel is so big that .text is large enough that the linker >>cannot handle some of the relocations to places in .text3 resulting in >>truncating the relocations. Any ideas on fixing this? > > Has any checked to see if arranging the atomic operation logic to > avoid a forward branch in the success case actually provides a > performance benefit? I don't know. I think we may have gotten them that way from NetBSD. It is how the Brown Book recommends that one do things. However, the Brown Book didn't recommend jumping to the end of the kernel and back either. :-( > Unless the kernel is covered by either super-page or large-page ITB > mappings, the cost of a likely ITB miss will outweigh the branch > prediction benefits. There's also a probable Icache (and maybe other > caches) miss. Also, not all the AXP implementations actually use the > branch direction for prediction. The 2106xA variants all use a 2-bit > history in the Icache (with a new line just inheriting whatever's left > over from the previous entry). I'm not sure about more recent chips > (I don't have the specs to hand). > > The only other option I can see is a new section tag that means "load > this section after any similarly-named sections within the current > module". This would push the forward branches to the end of the > current module rather than the end of the kernel. The downside is > that it means more custom hacks to gas and ld. Well, custom hacks to binutils would be a Bad Thing (tm). Perhaps there is already a way to do this in gas and ld that we just don't know about? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message