From owner-svn-src-stable@freebsd.org Mon Aug 14 11:04:07 2017 Return-Path: Delivered-To: svn-src-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B6695DE31C2; Mon, 14 Aug 2017 11:04:07 +0000 (UTC) (envelope-from kib@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 84A977766F; Mon, 14 Aug 2017 11:04:07 +0000 (UTC) (envelope-from kib@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id v7EB46DR015190; Mon, 14 Aug 2017 11:04:06 GMT (envelope-from kib@FreeBSD.org) Received: (from kib@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id v7EB46pD015189; Mon, 14 Aug 2017 11:04:06 GMT (envelope-from kib@FreeBSD.org) Message-Id: <201708141104.v7EB46pD015189@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: kib set sender to kib@FreeBSD.org using -f From: Konstantin Belousov Date: Mon, 14 Aug 2017 11:04:06 +0000 (UTC) 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 X-SVN-Group: stable-11 X-SVN-Commit-Author: kib X-SVN-Commit-Paths: stable/11/sys/amd64/amd64 X-SVN-Commit-Revision: 322491 X-SVN-Commit-Repository: base MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for all the -stable branches of the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 11:04:07 -0000 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)