Date: Mon, 14 Aug 2017 11:04:06 +0000 (UTC) From: Konstantin Belousov <kib@FreeBSD.org> To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-stable@freebsd.org, svn-src-stable-11@freebsd.org Subject: svn commit: r322491 - stable/11/sys/amd64/amd64 Message-ID: <201708141104.v7EB46pD015189@repo.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: kib Date: Mon Aug 14 11:04:06 2017 New Revision: 322491 URL: https://svnweb.freebsd.org/changeset/base/322491 Log: MFC r322171: Explain why delayed invalidation is not required in pmap_protect() and pmap_remove_pages(). Modified: stable/11/sys/amd64/amd64/pmap.c Directory Properties: stable/11/ (props changed) Modified: stable/11/sys/amd64/amd64/pmap.c ============================================================================== --- stable/11/sys/amd64/amd64/pmap.c Mon Aug 14 06:46:15 2017 (r322490) +++ stable/11/sys/amd64/amd64/pmap.c Mon Aug 14 11:04:06 2017 (r322491) @@ -4055,6 +4055,26 @@ pmap_protect(pmap_t pmap, vm_offset_t sva, vm_offset_t PG_RW = pmap_rw_bit(pmap); anychanged = FALSE; + /* + * Although this function delays and batches the invalidation + * of stale TLB entries, it does not need to call + * pmap_delayed_invl_started() and + * pmap_delayed_invl_finished(), because it does not + * ordinarily destroy mappings. Stale TLB entries from + * protection-only changes need only be invalidated before the + * pmap lock is released, because protection-only changes do + * not destroy PV entries. Even operations that iterate over + * a physical page's PV list of mappings, like + * pmap_remove_write(), acquire the pmap lock for each + * mapping. Consequently, for protection-only changes, the + * pmap lock suffices to synchronize both page table and TLB + * updates. + * + * This function only destroys a mapping if pmap_demote_pde() + * fails. In that case, stale TLB entries are immediately + * invalidated. + */ + PMAP_LOCK(pmap); for (; sva < eva; sva = va_next) { @@ -5378,6 +5398,15 @@ pmap_page_is_mapped(vm_page_t m) * no processor is currently accessing the user address space. In * particular, a page table entry's dirty bit won't change state once * this function starts. + * + * Although this function destroys all of the pmap's managed, + * non-wired mappings, it can delay and batch the invalidation of TLB + * entries without calling pmap_delayed_invl_started() and + * pmap_delayed_invl_finished(). Because the pmap is not active on + * any other processor, none of these TLB entries will ever be used + * before their eventual invalidation. Consequently, there is no need + * for either pmap_remove_all() or pmap_remove_write() to wait for + * that eventual TLB invalidation. */ void pmap_remove_pages(pmap_t pmap)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201708141104.v7EB46pD015189>