summaryrefslogtreecommitdiffstats
path: root/sys/i386/include/param.h
diff options
context:
space:
mode:
authoralc <alc@FreeBSD.org>2008-03-27 04:34:17 +0000
committeralc <alc@FreeBSD.org>2008-03-27 04:34:17 +0000
commit2a244be0948ebf54f47b701a69bdc0acbc452299 (patch)
tree71fd377cd39a489531c67dbd62417bb6bf1cd6d3 /sys/i386/include/param.h
parent669aee5e4400017ab51274cecbb9a12d7913543b (diff)
downloadFreeBSD-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 'sys/i386/include/param.h')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud