Date: Wed, 22 Aug 2001 15:55:18 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Mitsuru IWASAKI <iwasaki@jp.FreeBSD.org> Cc: <peter@wemm.org>, <arch@FreeBSD.ORG>, <audit@FreeBSD.ORG>, <kumabu@t3.rim.or.jp> Subject: Re: CFR: Timing to enable CR4.PGE bit Message-ID: <20010822154635.P6058-100000@besplex.bde.org> In-Reply-To: <20010822020634P.iwasaki@jp.FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 22 Aug 2001, Mitsuru IWASAKI wrote:
> Hi, thanks peter for your comments.
> > The G bit does not "lock" the TLB entries in. All it does is stop
> > unnecessary flushes when %cr3 is changed. If entries are not used
> > for a short while, they will be recycled when the TLB slot is needed
> > for something else soon enough. ie: this should not be a problem.
>
> My point is that users need higher system performance in multi-user
> environment rather than in kernel bootstrap. Also PGE bit has effects
> in multi-user environment where %cr3 is changed frequently.
> I think enabling PGE in early stage of kernel bootstrap won't give us
> performance advantages, entries which is used in bootstrap will remain
> in the TLB as Intel's document says;
> ----
> 3.7. TRANSLATION LOOKASIDE BUFFERS (TLBS)
> [snip]
> When the processor loads a page-directory or page-table entry for a
> global page into a TLB, the entry will remain in the TLB indefinitely.
^^^^^^^^^^^^
> The only way to deterministically invalidate global page entries is to
> clear the PGE flag and then invalidate the TLBs or to use the INVLPG
> instruction to invalidate individual page-directory or page-table
> entries in the TLBs.
> ----
I think this just means that it is hard to say how long the entries remain
in the TLB, not thatthey remain there forever.
> According to i386/locore.s, it seems that PTEs for kernel text, data,
> bss and symbols have PG_G bit, I worry that it is enough many to fill
> TLB slot out...
>
> > Regardless of my doubts above, I do have a problem with the patch...
> > It only works for the PPro/p2/p3 and not the p4. Is this intentional?
> > All have the CPUID_PGE bit. I think the test for cpu_id & 0x600 is
> > bogus and should be removed.
Another thing I don't like about it: it uses a SYSINIT() so it obfuscates
the initialization order. The problem fixed by the other half of your
patch shows that it's hard enough to get the order right when the
initializations are done inline.
Bruce
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?20010822154635.P6058-100000>