mirror of
https://git.FreeBSD.org/src.git
synced 2024-12-25 11:37:56 +00:00
Mirror of the FreeBSD src repository https://git.FreeBSD.org/src.git .
56e61f57b0
The only current purpose of the pvh lock was explained there On Wed, Jan 09, 2013 at 11:46:13PM -0600, Alan Cox wrote: > Let me lay out one example for you in detail. Suppose that we have > three processors and two of these processors are actively using the same > pmap. Now, one of the two processors sharing the pmap performs a > pmap_remove(). Suppose that one of the removed mappings is to a > physical page P. Moreover, suppose that the other processor sharing > that pmap has this mapping cached with write access in its TLB. Here's > where the trouble might begin. As you might expect, the processor > performing the pmap_remove() will acquire the fine-grained lock on the > PV list for page P before destroying the mapping to page P. Moreover, > this processor will ensure that the vm_page's dirty field is updated > before releasing that PV list lock. However, the TLB shootdown for this > mapping may not be initiated until after the PV list lock is released. > The processor performing the pmap_remove() is not problematic, because > the code being executed by that processor won't presume that the mapping > is destroyed until the TLB shootdown has completed and pmap_remove() has > returned. However, the other processor sharing the pmap could be > problematic. Specifically, suppose that the third processor is > executing the page daemon and concurrently trying to reclaim page P. > This processor performs a pmap_remove_all() on page P in preparation for > reclaiming the page. At this instant, the PV list for page P may > already be empty but our second processor still has a stale TLB entry > mapping page P. So, changes might still occur to the page after the > page daemon believes that all mappings have been destroyed. (If the PV > entry had still existed, then the pmap lock would have ensured that the > TLB shootdown completed before the pmap_remove_all() finished.) Note, > however, the page daemon will know that the page is dirty. It can't > possibly mistake a dirty page for a clean one. However, without the > current pvh global locking, I don't think anything is stopping the page > daemon from starting the laundering process before the TLB shootdown has > completed. > > I believe that a similar example could be constructed with a clean page > P' and a stale read-only TLB entry. In this case, the page P' could be > "cached" in the cache/free queues and recycled before the stale TLB > entry is flushed. TLBs for addresses with updated PTEs are always flushed before pmap lock is unlocked. On the other hand, amd64 pmap code does not always flushes TLBs before PV list locks are unlocked, if previously PTEs were cleared and PV entries removed. To handle the situations where a thread might notice empty PV list but third thread still having access to the page due to TLB invalidation not finished yet, introduce delayed invalidation. Comparing with the pvh_global_lock, DI does not block entered thread when pmap_remove_all() or pmap_remove_write() (callers of pmap_delayed_invl_wait()) are executed in parallel. But _invl_wait() callers are blocked until all previously noted DI blocks are leaved, thus ensuring that neccessary TLB invalidations were performed before returning from pmap_remove_all() or pmap_remove_write(). See comments for detailed description of the mechanism, and also for the explanations why several pmap methods, most important pmap_enter(), do not need DI protection. Reviewed by: alc, jhb (turnstile KPI usage) Tested by: pho (previous version) Sponsored by: The FreeBSD Foundation Differential revision: https://reviews.freebsd.org/D5747 |
||
|---|---|---|
| bin | ||
| cddl | ||
| contrib | ||
| crypto | ||
| etc | ||
| gnu | ||
| include | ||
| kerberos5 | ||
| lib | ||
| libexec | ||
| release | ||
| rescue | ||
| sbin | ||
| secure | ||
| share | ||
| sys | ||
| targets | ||
| tests | ||
| tools | ||
| usr.bin | ||
| usr.sbin | ||
| .arcconfig | ||
| .arclint | ||
| COPYRIGHT | ||
| LOCKS | ||
| MAINTAINERS | ||
| Makefile | ||
| Makefile.inc1 | ||
| Makefile.libcompat | ||
| ObsoleteFiles.inc | ||
| README | ||
| UPDATING | ||
This is the top level of the FreeBSD source directory. This file was last revised on: $FreeBSD$ For copyright information, please see the file COPYRIGHT in this directory (additional copyright information also exists for some sources in this tree - please see the specific source directories for more information). The Makefile in this directory supports a number of targets for building components (or all) of the FreeBSD source tree. See build(7) and http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html for more information, including setting make(1) variables. The `buildkernel` and `installkernel` targets build and install the kernel and the modules (see below). Please see the top of the Makefile in this directory for more information on the standard build targets and compile-time flags. Building a kernel is a somewhat more involved process. See build(7), config(8), and http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig.html for more information. Note: If you want to build and install the kernel with the `buildkernel` and `installkernel` targets, you might need to build world before. More information is available in the handbook. The kernel configuration files reside in the sys/<arch>/conf sub-directory. GENERIC is the default configuration used in release builds. NOTES contains entries and documentation for all possible devices, not just those commonly used. Source Roadmap: --------------- bin System/user commands. cddl Various commands and libraries under the Common Development and Distribution License. contrib Packages contributed by 3rd parties. crypto Cryptography stuff (see crypto/README). etc Template files for /etc. games Amusements. gnu Various commands and libraries under the GNU Public License. Please see gnu/COPYING* for more information. include System include files. kerberos5 Kerberos5 (Heimdal) package. lib System libraries. libexec System daemons. release Release building Makefile & associated tools. rescue Build system for statically linked /rescue utilities. sbin System commands. secure Cryptographic libraries and commands. share Shared resources. sys Kernel sources. tests Regression tests which can be run by Kyua. See tests/README for additional information. tools Utilities for regression testing and miscellaneous tasks. usr.bin User commands. usr.sbin System administration commands. For information on synchronizing your source tree with one or more of the FreeBSD Project's development branches, please see: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/synching.html