Date: Wed, 22 Aug 2001 01:49:00 -0700 From: Peter Wemm <peter@wemm.org> To: tlambert2@mindspring.com Cc: Mitsuru IWASAKI <iwasaki@jp.FreeBSD.org>, arch@FreeBSD.ORG, audit@FreeBSD.ORG, kumabu@t3.rim.or.jp Subject: Re: CFR: Timing to enable CR4.PGE bit Message-ID: <20010822084900.4306738FD@overcee.netplex.com.au> In-Reply-To: <3B836737.9C15EA8@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010822084900.4306738FD>