Date: Tue, 1 Jun 2004 17:38:07 -0700 From: Marcel Moolenaar <marcel@xcllnt.net> To: Arun Sharma <arun.sharma@intel.com> Cc: freebsd-ia64@freebsd.org Subject: Re: invala Message-ID: <20040602003807.GA17999@dhcp50.pn.xcllnt.net> In-Reply-To: <40BD08E8.3090608@intel.com> References: <40A2A0A2.8040004@intel.com> <20040512232827.GB45389@ns1.xcllnt.net> <40A2D3D7.4030804@intel.com> <20040513053053.GA4487@dhcp01.pn.xcllnt.net> <40A3F9DD.8080201@intel.com> <20040514002345.GA50681@ns1.xcllnt.net> <40BD08E8.3090608@intel.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jun 01, 2004 at 03:53:28PM -0700, Arun Sharma wrote: > On 5/13/2004 5:23 PM, Marcel Moolenaar wrote: > > >I agree that we need to pay attention to it, but I'd like to have a > >more detailed analysis before we add invala instructions. I feel that > >invalidating the ALAT on entry into the kernel and on exit from the > >kernel is too much of a pessimization. I can easily be wrong... > > > > A quick and dirty program seems to indicate that we pay only of the order > of two cycles. The cost of keeping track of whether a mapping changed in > pmap might be more. Well, the 2-cycle latency is something you pay for with every entry into and exit from the kernel if you put it there. Since it will be in the critical path then, the impact may be more severe than when you spend thousands of cycles when you actually need to do the invala. > The cost for heavily speculative code might be more due to failed > speculation after invala. Yes. If and when we have significant speculation on a regular basis on ia64, the invala, while cheap by itself, may further induce significant performance loss by having the speculation fail for no apparent reason. It's not so much the cost of the instruction itself that worries me, but the effect it has on application performance. > But since we don't have such programs on FreeBSD > yet (to the best of my knowledge), we lack the data to figure out what the > hidden cost is. Well, we should be able to figure out under what conditions an invala is required. From there we can infer when in the FreeBSD kernel we possibly need an invala and also what it would take to do one only when needed. I expect that the cost to be exact would not weigh up against the cost of an excessive invala here and there, so we should end up with a compromise that should not be too far removed from an ideal situation. If this ends up with an invala on entry into the kernel and an invala on exit from the kernel than so be it... -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040602003807.GA17999>