From owner-freebsd-arch Wed Aug 22 1:49:17 2001 Delivered-To: freebsd-arch@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [24.14.150.180]) by hub.freebsd.org (Postfix) with ESMTP id 82B5837B413; Wed, 22 Aug 2001 01:49:00 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f7M8n0M78097; Wed, 22 Aug 2001 01:49:00 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 4306738FD; Wed, 22 Aug 2001 01:49:00 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: tlambert2@mindspring.com Cc: Mitsuru IWASAKI , arch@FreeBSD.ORG, audit@FreeBSD.ORG, kumabu@t3.rim.or.jp Subject: Re: CFR: Timing to enable CR4.PGE bit In-Reply-To: <3B836737.9C15EA8@mindspring.com> Date: Wed, 22 Aug 2001 01:49:00 -0700 From: Peter Wemm Message-Id: <20010822084900.4306738FD@overcee.netplex.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Terry Lambert wrote: [the other part] > To me, it seems that this will load the PGE bit enabled > entries for the 4K pages into core exceptionally early, and > that doing this will conflict with the later 4M page entry, > which will end up having its own mapping (since 4M pages have > their own, seperate table), and thus I will end up with two > mappings for the same pages, neither of which can be easily > invalidated on a P3 or P4 without toggling PGE off first, > since they all have the PG_G bit set in them. While this is true, we do not change the wiring of the text+data+bss virtual -> physical pages that are double-mapped when we round up to the 4MB boundary. (see pmap_choose_addr() for the roundup) While they should never conflict and are never changed, I could imagine that having 4K and 4MB tlb's matching on the same virtual address could possibly cause some odd behavior, I'm a little doubtful. I would have expected it to turn up on other cpu brands (eg: athlon, transmeta etc) by now. > I can tell you from personal experience on a Tyan Tiger > with 1G of RAM and on a Super Micro with 4G of RAM that > this can lead to very bad problems, unless you have enough > entries being made in the KVA space to cause the invalidations > to LRU out the pages... specifically, I saw some very > interesting faults with mbufs, until I grew some kernel > structures large enough to force the shootdown during the > normal boot process, and it wasn't until later that I > recognized the origin of the problem. It would be cleaner to make a decision once in pmap_bootstrap() that went through and flipped PG_G on either the the 4MB page or the underlying 4K pages. That way there would be no possible overlapping PG_G tlb entries. > It used to be that you could just reload CR3 with the same > value to force an invalidation of pages without PG_G set > with PGE enabled, or with PG_G set, without PGE enabled, > but that's no longer true on newer systems, which will > forego the invalidation if you are reloading the same value > (for obvious performance reasons). I dont think we did this anyway. Once set, PG_G and PGE stayed set forever. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message