From owner-freebsd-arch Wed Aug 22 0:53:39 2001 Delivered-To: freebsd-arch@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [24.14.150.180]) by hub.freebsd.org (Postfix) with ESMTP id 3802137B40D; Wed, 22 Aug 2001 00:53:33 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f7M7rXM77828; Wed, 22 Aug 2001 00:53:33 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id F003238FD; Wed, 22 Aug 2001 00:53:32 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Mitsuru IWASAKI Cc: arch@FreeBSD.ORG, audit@FreeBSD.ORG, kumabu@t3.rim.or.jp Subject: Re: CFR: Timing to enable CR4.PGE bit In-Reply-To: <20010822020634P.iwasaki@jp.FreeBSD.org> Date: Wed, 22 Aug 2001 00:53:32 -0700 From: Peter Wemm Message-Id: <20010822075332.F003238FD@overcee.netplex.com.au> 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 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