Date: Wed, 22 Aug 2001 00:53:32 -0700 From: Peter Wemm <peter@wemm.org> To: Mitsuru IWASAKI <iwasaki@jp.FreeBSD.org> Cc: arch@FreeBSD.ORG, audit@FreeBSD.ORG, kumabu@t3.rim.or.jp Subject: Re: CFR: Timing to enable CR4.PGE bit Message-ID: <20010822075332.F003238FD@overcee.netplex.com.au> In-Reply-To: <20010822020634P.iwasaki@jp.FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Mitsuru IWASAKI wrote: > > However: > > > > > Also I have another thing to be confirmed. Should we utilize TLB by > > > enabling PGE bit at very later stage? I think it would be more > > > efficient to cache page entries with G flag in multi-user environment, > > > not in kernel bootstrap. If we enable PGE bit in locore.s, TLB could > > > be occupied by entries which is referenced by initialization code > > > (yes, most of them are executed only once). > > > # but I could be wrong... > > > > 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. > ---- > > 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... No. All that this means is that the cpu will not flush them with a %cr3 reload. The cpu will still recycle the TLB slots as it sees fit. It just wont do it because we switch tasks. This is exactly what we want. PG_G does not mean they will stay there forever. If it did, then merely having 64 pages with PG_G set would mean we would lock up all the TLB entries forever. On a generic kernel, there are 154 pages of data + bss alone. If they were unable to be flushed from the tlb, then that would account for more than all tlb slots on current cpus. 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?20010822075332.F003238FD>