First Montecito Reference Manual is now available

First Montecito Reference Manual is now available

[Luck, Tony]

The Dual-Core Update to the Intel Itanium 2 Processor 
Reference Manual is now available publicly at:

http://developer.intel.com/design/itanium2/manuals/308065.htm:

This document is our first public release of the Montecito 
micro-architecture and describes the micro-architectural 
changes in the Montecito processor, including cache 
hierarchies, memory management, and instruction execution 
latencies.  This manual is targeted for developers of 
compilers and performance software and contains information 
regarding optimization via performance monitoring events.  

-Tony

Re: First Montecito Reference Manual is now available

[Ian Wienand]

[-- Attachment #1: Type: text/plain, Size: 607 bytes --]

On Mon, Jan 16, 2006 at 08:32:56PM -0800, Luck, Tony wrote:
> The Dual-Core Update to the Intel Itanium 2 Processor 
> Reference Manual is now available publicly

On page 173 it mentions "cycles we run with PCR.sd" set.  What's that?

On page 174 it talks about THREAD_SWITCH_GATED.  What is a gated
thread switch?  Particularly it mentions being gated due to LP, what
is that?

On page 176 it mentions a srlz.i instruction causes a "microtrap" and
an xpn-flush.  What are they?

TLB entries are tagged with the hardware thread.  Is there any
possibility to override this (I mean, even theoretically)?

-i


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: First Montecito Reference Manual is now available

[Luck, Tony]

Ian,

Thanks for taking the time to look at this document. Here are the
answers from an Itanium architect:

> On page 173 it mentions "cycles we run with PCR.sd" set.  What's that?
A1)  This is a too low level reference.  It basically indicates the
cycles where we artificially prevent thread switching from occurring.
Only firmware has the ability to do this.  It should very low.  I will
make a note to ensure this is addressed in 1.0.

> On page 174 it talks about THREAD_SWITCH_GATED.  What is a gated
> thread switch?  Particularly it mentions being gated due to LP, what
> is that?
A2) A thread switch has been queued, but can be delayed for various
reasons -- specifically if target thread is in low-power mode (LP),
there are pipeline stalls that need to be removed in order to complete
architectural state of the source thread, and for forward progress
(we have not given the current thread sufficient time in the core).
I will see about getting LP addressed and explained better.

> On page 176 it mentions a srlz.i instruction causes a "microtrap" and
> an xpn-flush.  What are they?
[Ref is actually on p.164, p.176 is blank]
A3) Again this is too low level and should be changed to be something
like: "(because it causes a pipeline flush)".  The other information is
how it does the flush and not relevant.

> TLB entries are tagged with the hardware thread.  Is there any
> possibility to override this (I mean, even theoretically)?
A4) The thread identifier is considered part of the VA to ensure that VA
and PA aliases between threads do not turn up problems (such as different
access rights and or accessed/dirty behaviors.  It cannot be undone.
There is some thread TLB aliasing that is allowed in the L1I TLB but
we actually cause a miss on the old thread and then re-insert the new
thread's page information on top of the old thread.  This preserves the
L1I cache contents for that 4k L1I TLB entry.

-Tony

Re: [ia64-technical] Re: First Montecito Reference Manual is now available

[Matthew Chapman]

On Tue, Jan 17, 2006 at 11:22:28AM -0800, Luck, Tony wrote:
> 
> > TLB entries are tagged with the hardware thread.  Is there any
> > possibility to override this (I mean, even theoretically)?
> A4) The thread identifier is considered part of the VA to ensure that VA
> and PA aliases between threads do not turn up problems (such as different
> access rights and or accessed/dirty behaviors.  It cannot be undone.

For the record, I'm a little disappointed about this decision not to
make the tagging feature configurable (via an MSR).

Now I agree that thread tagging is the right default, for the benefit of
legacy operating systems that may use CPU-local mappings in a way that
would not be safe if the TLBs weren't thread-tagged.

However, this means that OSs that are aware of the system topology must
nonetheless pay the performance price of a TLB that is effectively
smaller.

It seems to me that, at least at the L2TLB level, the "untagged" model
could be implemented as an alternative at minimal cost;  e.g. OR the
control bit into the tag.  L1TLBs obviously have much tighter timing
constraints, but the technique that is implemented for the L1ITLB would
work in any case.

I'm aware of a couple of architectures that have TLBs shared between
threads without explicit thread-tagging, and I'm sure that there's more
to come...  so this is something that OSs will eventually have to deal
with anyway.

Matt

Re: [ia64-technical] Re: First Montecito Reference Manual is now available

[Matthew Chapman]

On Thu, Jan 19, 2006 at 12:14:53AM +1100, Matthew Chapman wrote:
> 
> It seems to me that, at least at the L2TLB level, the "untagged" model
> could be implemented as an alternative at minimal cost;  e.g. OR the
> control bit into the tag.

Having thought it through, it may not be quite that simple, because of
RR prevalidation.  I'd guess that perhaps on Montecito the Active (RR
match) bit is set on both sets of entries to avoid revalidation on
thread switch?  And you sure don't want the set of mappings merged if
the two threads have different RRs!

In principle I still like the idea of an untagged mode, however...
especially since Itanium is targetted at HPC, and such workloads tend
to have overlap in working sets.  Just my 2c :)

Matt