From owner-freebsd-alpha Mon Apr 26 13:55:18 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29]) by hub.freebsd.org (Postfix) with ESMTP id 5A72E14FD6 for ; Mon, 26 Apr 1999 13:54:52 -0700 (PDT) (envelope-from thorpej@lestat.nas.nasa.gov) Received: from lestat (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.8/8.6.12) with ESMTP id NAA11457; Mon, 26 Apr 1999 13:53:53 -0700 (PDT) Message-Id: <199904262053.NAA11457@lestat.nas.nasa.gov> To: Dmitrij Tejblum Cc: Doug Rabson , Dmitrij Tejblum , freebsd-alpha@FreeBSD.ORG Subject: Re: "I-stream memory barrier" Reply-To: Jason Thorpe From: Jason Thorpe Date: Mon, 26 Apr 1999 13:53:53 -0700 Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 27 Apr 1999 00:24:55 +0400 Dmitrij Tejblum 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message