From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 63A6CC19F28 for ; Wed, 3 Aug 2022 10:18:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F1D8C6B0071; Wed, 3 Aug 2022 06:18:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id ECD246B0072; Wed, 3 Aug 2022 06:18:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D95278E0001; Wed, 3 Aug 2022 06:18:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id C84B16B0071 for ; Wed, 3 Aug 2022 06:18:04 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 954B2C14B9 for ; Wed, 3 Aug 2022 10:18:04 +0000 (UTC) X-FDA: 79757880888.10.F7C610A Received: from mga06.intel.com (mga06b.intel.com [134.134.136.31]) by imf08.hostedemail.com (Postfix) with ESMTP id 00AB8160022 for ; Wed, 3 Aug 2022 10:18:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1659521884; x=1691057884; h=date:from:to:cc:subject:message-id:reply-to:references: mime-version:in-reply-to; bh=wFam+LDcRbKILr0ubXYReeOGRVLmWUy4n8feDpXT4KY=; b=cxaeXmovr+oUSgj1TIIUIEJQzPwrv/Fng0HpeVZKGQ9+qDxHi9YSv2yZ 0F9bdNH2OZ2rzq1oiwXGcs/Ps+f6WX39+B7iIYx/sazU8UT5tKOiOi3H4 58W7NjHlAXLjelofnXeYj+PeCprHMRZakeFiBpZdwpqfrJqQ1n+HjEsVx 26U4Cs3zR5SJ9zmntf7dTAa3FDe7MpUqez35fVfn48SF+tfvBfQJE7nQB XSPNYQTrx3SqYyEiDgmHEkakv+cojQ6zfYYeDJyP25qD93xgnq+8okx7Z B14eybxJzv+3pbFQdWteJAQ65gBJpKuKyTHjBV9Nj2jqogYtzVheJZ9ge A==; X-IronPort-AV: E=McAfee;i="6400,9594,10427"; a="351350450" X-IronPort-AV: E=Sophos;i="5.93,213,1654585200"; d="scan'208";a="351350450" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Aug 2022 03:18:02 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.93,213,1654585200"; d="scan'208";a="631095811" Received: from chaop.bj.intel.com (HELO localhost) ([10.240.193.75]) by orsmga008.jf.intel.com with ESMTP; 03 Aug 2022 03:17:51 -0700 Date: Wed, 3 Aug 2022 18:13:04 +0800 From: Chao Peng To: Sean Christopherson Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-api@vger.kernel.org, linux-doc@vger.kernel.org, qemu-devel@nongnu.org, linux-kselftest@vger.kernel.org, Paolo Bonzini , Jonathan Corbet , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, "H . Peter Anvin" , Hugh Dickins , Jeff Layton , "J . Bruce Fields" , Andrew Morton , Shuah Khan , Mike Rapoport , Steven Price , "Maciej S . Szmigiero" , Vlastimil Babka , Vishal Annapurve , Yu Zhang , "Kirill A . Shutemov" , luto@kernel.org, jun.nakajima@intel.com, dave.hansen@intel.com, ak@linux.intel.com, david@redhat.com, aarcange@redhat.com, ddutile@redhat.com, dhildenb@redhat.com, Quentin Perret , Michael Roth , mhocko@suse.com, Muchun Song Subject: Re: [PATCH v7 08/14] KVM: Rename mmu_notifier_* Message-ID: <20220803101304.GE607465@chaop.bj.intel.com> Reply-To: Chao Peng References: <20220706082016.2603916-1-chao.p.peng@linux.intel.com> <20220706082016.2603916-9-chao.p.peng@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1659521884; h=from:from:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=dZuXVKcaDKwEQkILsmWt2bqndYdaJ10vS5x9+2OthmY=; b=IzfISjDdzuF0CnnHn0/o1cVv1c/MYz+zowgh77zT0r/Mg9mi7cPVxnoalqX+ufNQ3ZXhpx DcVlhUzzC/bPmUlARWwByxlKDgHQvfgz79TC/kYc2MAGVR01q62CByE89bz0gksmCcnxQU mm4X24aZ7t1Hem9jKx4c+RyYpPo9TFw= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=cxaeXmov; spf=none (imf08.hostedemail.com: domain of chao.p.peng@linux.intel.com has no SPF policy when checking 134.134.136.31) smtp.mailfrom=chao.p.peng@linux.intel.com; dmarc=fail reason="No valid SPF" header.from=intel.com (policy=none) ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1659521884; a=rsa-sha256; cv=none; b=tj99ZpVUsrYkjLSWjpe4zYU/9oo3x2aIFQfNsz4xjBKl2yWaC+NONaM8mg3zNm3m5i6XCS 87lhEumqqg24gM1rSogz+kFQ/WuY3f1lE3NJHb6d6X5n420TVuY5FC7Y1KYfgw/ChwAX2f Gm6nZV8V4MkdKV1diDuy+/KtQUOMEAE= Authentication-Results: imf08.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=cxaeXmov; spf=none (imf08.hostedemail.com: domain of chao.p.peng@linux.intel.com has no SPF policy when checking 134.134.136.31) smtp.mailfrom=chao.p.peng@linux.intel.com; dmarc=fail reason="No valid SPF" header.from=intel.com (policy=none) X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 00AB8160022 X-Stat-Signature: mmhcncik946isi99btk6meoafda55xtj X-HE-Tag: 1659521883-378844 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Jul 29, 2022 at 07:02:12PM +0000, Sean Christopherson wrote: > On Wed, Jul 06, 2022, Chao Peng wrote: > > The sync mechanism between mmu_notifier and page fault handler employs > > fields mmu_notifier_seq/count and mmu_notifier_range_start/end. For the > > to be added private memory, there is the same mechanism needed but not > > rely on mmu_notifier (It uses new introduced memfile_notifier). This > > patch renames the existing fields and related helper functions to a > > neutral name mmu_updating_* so private memory can reuse. > > mmu_updating_* is too broad of a term, e.g. page faults and many other operations > also update the mmu. Although the name most definitely came from the mmu_notifier, > it's not completely inaccurate for other sources, e.g. KVM's MMU is still being > notified of something, even if the source is not the actual mmu_notifier. > > If we really want a different name, I'd vote for nomenclature that captures the > invalidation aspect, which is really what the variables are all trackng, e.g. > > mmu_invalidate_seq > mmu_invalidate_in_progress > mmu_invalidate_range_start > mmu_invalidate_range_end Looks good to me. Thanks. Chao