Date: Thu, 14 Nov 2002 07:26:36 +1100 From: Peter Jeremy <peter.jeremy@alcatel.com.au> To: John Baldwin <jhb@FreeBSD.ORG> Cc: alpha@FreeBSD.ORG Subject: Re: cvs commit: src/sys/conf files files.i386 files.pc98 Message-ID: <20021113202636.GA23652@gsmx07.alcatel.com.au> In-Reply-To: <XFMail.20021108175520.jhb@FreeBSD.org> References: <200211082233.gA8MXFSc085711@repoman.freebsd.org> <XFMail.20021108175520.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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? 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. Peter 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?20021113202636.GA23652>