[no subject]

> > 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.

It also stops necessary ones, unless you bounce it off, hit
CR3, and bounce it back on... that's the strange code around
the 4M page enable code.

> 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.
> ----

The INVLPG doesn't work exactly like you think it should, with
PGE on, on more recent processors, unfortunately.


> 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...

The kernel is in a 4M page in most cases, so it's not an
issue in most cases.  It's really very important that you
not have to flush in the case of a kernel entry (interrupt,
system call, etc.), since it _will_ make a protection domain
crossing significantly more expensive.

Also, note that the 4M pages are in a seperate 8 entry conflict
domain, and aren't in the same 16 entry data or 16 entry
instruction TLB's, on every processor where they are supported,
so the kernel is not competing with user space code anyway.

NB: 4M pages only make sense in certain specific limited
situations... using up 4M chunks of KVA space is generally a
bad idea, unless the objects you are using them for are really
4M or larger in size.  This is particularly true on 4G machines,
where you really don't have any sparseness to burn on unused
pages, and can't afford to use the remainder space without the
same mapping you used for the rest of it (e.g. for libc.so, a
copy-on-write page that is also executable, unless you split
the code and data across the page boundary).

-- Terry

To Unsubscribe: send mail to majordomo@xxxxxxxxxxx
with "unsubscribe freebsd-audit" in the body of the message