summaryrefslogtreecommitdiffstats
path: root/sys/vm/vm_page.h
diff options
context:
space:
mode:
authoralc <alc@FreeBSD.org>2010-07-08 03:35:00 +0000
committeralc <alc@FreeBSD.org>2010-07-08 03:35:00 +0000
commit10f83cdf0a459ed959605be219efd36ff9183a1e (patch)
tree4991a91b654ff72b58c05faf176fb4d6120c703a /sys/vm/vm_page.h
parent5e2426bc109883c6a0e6cb07e0b07b4c7a78cccf (diff)
downloadFreeBSD-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/vm_page.h')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud