Date: Wed, 13 Nov 2002 16:41:31 -0500 (EST) From: John Baldwin <jhb@FreeBSD.org> To: Peter Jeremy <peter.jeremy@alcatel.com.au> Cc: alpha@FreeBSD.ORG Subject: Re: cvs commit: src/sys/conf files files.i386 files.pc98 Message-ID: <XFMail.20021113164131.jhb@FreeBSD.org> In-Reply-To: <20021113202636.GA23652@gsmx07.alcatel.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On 13-Nov-2002 Peter Jeremy wrote: > On 2002-Nov-08 17:55:20 -0500, John Baldwin <jhb@FreeBSD.ORG> 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 <jhb@FreeBSD.org> <>< 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.20021113164131.jhb>