From owner-freebsd-arch Wed Aug 22 1: 2:33 2001 Delivered-To: freebsd-arch@freebsd.org Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by hub.freebsd.org (Postfix) with ESMTP id DA48F37B403; Wed, 22 Aug 2001 01:02:25 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.135.228.Dial1.SanJose1.Level3.net [209.245.135.228]) by snipe.mail.pas.earthlink.net (8.11.5/8.9.3) with ESMTP id f7M82Kh04101; Wed, 22 Aug 2001 01:02:20 -0700 (PDT) Message-ID: <3B836737.9C15EA8@mindspring.com> Date: Wed, 22 Aug 2001 01:03:03 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Wemm Cc: Mitsuru IWASAKI , arch@FreeBSD.ORG, audit@FreeBSD.ORG, kumabu@t3.rim.or.jp Subject: Re: CFR: Timing to enable CR4.PGE bit References: <20010822073628.B64AB38FD@overcee.netplex.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Peter Wemm wrote: > Terry Lambert wrote: > > Mitsuru IWASAKI wrote: > > > > This part is fine. > > > > > > OK, I'll commit this one first. > > > > What does setting PGE early do for you? > > The change is to avoid violating the rules in the CPU developers > guide. Did you read the thread? Yes. I still don't get what rules are being broken (no one quoted anything in comments inline in the code, citing the relevent pages in the guide, with a URL for the guide, for example). Let me ask again: what was broken before that is now fixed? 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. 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 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). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message