Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 26 Apr 1999 13:53:53 -0700
From:      Jason Thorpe <thorpej@nas.nasa.gov>
To:        Dmitrij Tejblum <tejblum@arc.hq.cti.ru>
Cc:        Doug Rabson <dfr@nlsystems.com>, Dmitrij Tejblum <dima@tejblum.dnttm.rssi.ru>, freebsd-alpha@FreeBSD.ORG
Subject:   Re: "I-stream memory barrier" 
Message-ID:  <199904262053.NAA11457@lestat.nas.nasa.gov>

next in thread | raw e-mail | index | archive | help
On Tue, 27 Apr 1999 00:24:55 +0400 
 Dmitrij Tejblum <tejblum@arc.hq.cti.ru> wrote:

 > > I'm pretty sure that I-cache lines are tagged with ASNs. The Linux kernel
 > > only calls imb() when it runs out of ASNs 
 > 
 > Well, you are right, even comments in the NetBSD pmap say so. Nevertheles, 
 > they call alpha_pal_imb() a lot - there should be a reason for that. 
 > Also, take a look at Linux' ev5_flush_tlb_current_page() - it flush whole ASN 
 > when it have to flush something executable, rather than do a TBIS.

Considering how I wrote a fairly significant portion of the NetBSD/alpha
pmap, I think I can speak with some authority here :-)

You'll note my comment about Address Space Numbers:

/*
 * Address Space Numbers.
 *
 * On many implementations of the Alpha architecture, the TLB entries and
 * I-cache blocks are tagged with a unique number within an implementation-
 * specified range.  When a process context becomes active, the ASN is used
 .
 .
 .
 */

`On many implementations', not on all.  Even though I know the I-cache layout
on the 21164, I didn't allow my pmap module to make any assumptions based on
that knowledge (I even ignored how IMB is implemented in the 21164 PALcode :-).

The architecture manual states that an IMB should be done whenever the mapping
for the I-stream changes.  This is in the IMB PALcode op description.  I
optimize out unnecessary IMBs on unmap by tracking VM_PROT_EXECUTE in a
software PTE bit.

Also note section 5.6.4.4 regarding the I-stream in the presence of
multiple processors (in this case, it includes I/O processors, i.e.
DMA engines on devices).  The way paging and COW are done in UVM (the
NetBSD virtual memory system) handles this case.

Basically, the NetBSD/alpha pmap is written to the architecture manual,
not to any specific processor manual, and will therefore Just Work with
any Alpha processor implementation.  And, modulo a silly optimization
error I made in modified/referenced emulation, the NetBSD/alpha pmap
has proven to be very stable.

        -- Jason R. Thorpe <thorpej@nas.nasa.gov>



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?199904262053.NAA11457>