Skip site navigation (1)Skip section navigation (2)
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>