diff options
author | alc <alc@FreeBSD.org> | 2010-07-08 03:35:00 +0000 |
---|---|---|
committer | alc <alc@FreeBSD.org> | 2010-07-08 03:35:00 +0000 |
commit | 10f83cdf0a459ed959605be219efd36ff9183a1e (patch) | |
tree | 4991a91b654ff72b58c05faf176fb4d6120c703a /sys/vm | |
parent | 5e2426bc109883c6a0e6cb07e0b07b4c7a78cccf (diff) | |
download | FreeBSD-src-10f83cdf0a459ed959605be219efd36ff9183a1e.zip FreeBSD-src-10f83cdf0a459ed959605be219efd36ff9183a1e.tar.gz |
Correctly maintain the per-cpu field "curpmap" on amd64 just like we
do on i386. The consequences of not doing so on amd64 became apparent
with the introduction of the COUNT_IPIS and COUNT_XINVLTLB_HITS
options. Specifically, single-threaded applications were generating
unnecessary IPIs to shoot-down the TLB on other processors. However,
this is clearly nonsensical because a single-threaded application is
only running on the current processor. The reason that this happens
is that pmap_activate() is unable to properly update the old pmap's
field "pm_active" without the correct "curpmap". So, in effect, stale
bits in "pm_active" were leading pmap_protect(), pmap_remove(),
pmap_remove_pages(), etc. to flush the TLB contents on some arbitrary
processor that wasn't even running the same application.
Reviewed by: kib
MFC after: 3 weeks
Diffstat (limited to 'sys/vm')
0 files changed, 0 insertions, 0 deletions