diff options
author | alc <alc@FreeBSD.org> | 2008-03-27 04:34:17 +0000 |
---|---|---|
committer | alc <alc@FreeBSD.org> | 2008-03-27 04:34:17 +0000 |
commit | 2a244be0948ebf54f47b701a69bdc0acbc452299 (patch) | |
tree | 71fd377cd39a489531c67dbd62417bb6bf1cd6d3 /contrib/opensolaris/lib/libuutil/common/libuutil_impl.h | |
parent | 669aee5e4400017ab51274cecbb9a12d7913543b (diff) | |
download | FreeBSD-src-2a244be0948ebf54f47b701a69bdc0acbc452299.zip FreeBSD-src-2a244be0948ebf54f47b701a69bdc0acbc452299.tar.gz |
MFamd64 with few changes:
1. Add support for automatic promotion of 4KB page mappings to 2MB page
mappings. Automatic promotion can be enabled by setting the tunable
"vm.pmap.pg_ps_enabled" to a non-zero value. By default, automatic
promotion is disabled. Tested by: kris
2. To date, we have assumed that the TLB will only set the PG_M bit in a
PTE if that PTE has the PG_RW bit set. However, this assumption does
not hold on recent processors from Intel. For example, consider a PTE
that has the PG_RW bit set but the PG_M bit clear. Suppose this PTE
is cached in the TLB and later the PG_RW bit is cleared in the PTE,
but the corresponding TLB entry is not (yet) invalidated.
Historically, upon a write access using this (stale) TLB entry, the
TLB would observe that the PG_RW bit had been cleared and initiate a
page fault, aborting the setting of the PG_M bit in the PTE. Now,
however, P4- and Core2-family processors will set the PG_M bit before
observing that the PG_RW bit is clear and initiating a page fault. In
other words, the write does not occur but the PG_M bit is still set.
The real impact of this difference is not that great. Specifically,
we should no longer assert that any PTE with the PG_M bit set must
also have the PG_RW bit set, and we should ignore the state of the
PG_M bit unless the PG_RW bit is set.
Diffstat (limited to 'contrib/opensolaris/lib/libuutil/common/libuutil_impl.h')
0 files changed, 0 insertions, 0 deletions