Date: Thu, 23 Aug 2001 01:40:25 +0900 From: Mitsuru IWASAKI <iwasaki@jp.FreeBSD.org> To: tlambert2@mindspring.com Cc: peter@wemm.org, 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: <20010823014025T.iwasaki@jp.FreeBSD.org> In-Reply-To: <3B837418.2D5529E5@mindspring.com> References: <20010822082749.ED86038FD@overcee.netplex.com.au> <3B837418.2D5529E5@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, thanks folks for comments and sorry for my late reply. Terry Lambert wrote: > Peter Wemm wrote: > > Page Global Enable (bit 7 of CR4). (Introduced in the P6 family > > processors.) Enables the global page feature when set; disables the > > global page feature when clear. [snip] In addition, the bit must not > > ^^^^^^^^^^^^^^^^ > > be enabled before paging is enabled via CR0.PG. Program correctness > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > may be affected by reversing this sequence, and processor performance > > will be impacted. > > ---- > > > > Currently, we enable CR4.PGE bit in create_pagetables, then enable > > CR0.PG in locore.s. This seems to violate Intel's note. > > Ah. It looked like an inverted patch to me... it moved the > code from line 725 or so in locore.s to line 375. I've just committed only part of moving CR4.PGE enabling code after paging is enabled. It was my primary goal to avoid violating the rules in the CPU developer's manual. Thanks folks! Another part of my original post was just for my curiosity, it's not so important. I thought it would be valuable to be considered if we can get better performance by moving CR4.PGE bit on to later stage without a lot of efforts. But I'm not sure how effective it is. There may be hardly effect. Does anyone test and measure it under suitable environment? If we get good result by this without any problems, then we can consider this issue again (including how to fire PGE enabling code as Bruce suggested), I think. Thanks 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?20010823014025T.iwasaki>