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 6C86EC3F6B0 for ; Fri, 19 Aug 2022 02:51:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DE1968E0001; Thu, 18 Aug 2022 22:51:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D906E8D0002; Thu, 18 Aug 2022 22:51:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C57C88E0001; Thu, 18 Aug 2022 22:51:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id B05438D0002 for ; Thu, 18 Aug 2022 22:51:37 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 6BD281A0AFD for ; Fri, 19 Aug 2022 02:51:37 +0000 (UTC) X-FDA: 79814816634.14.655B4B3 Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by imf30.hostedemail.com (Postfix) with ESMTP id D70A380003 for ; Fri, 19 Aug 2022 02:51:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1660877496; x=1692413496; h=from:to:cc:subject:references:date:in-reply-to: message-id:mime-version; bh=4EIcg7RWk2yRi+CSvUOFGKBdAdmQg2lkeFcyyl4c1Jg=; b=nHZxUeJInTnIDIr9t2VeTaQCF22mOMU9AcXKGgDX7/SdnID0NwU0GZQ+ lt+gLgM5CKCsGJ8qK3gPRC4X5PBZViUmKagr0CVWPYAdU/iav7mMryWF6 aVB4l2++ErtZy95l+t0X5mTeTkISJZFzpNyfTfxy3y5qGlQppoaruAJcq 0X+Ce9bjMwmiWGtERYEffsm/OzzRjpQ+n7WxqU192CoyxxPTEzz4x7/rM yFrULaHKeIfO5jzYUdtvRKSCDBMRUbGtWFh+npy6/Vn5DGxtqdZxggiF4 lv6xwHsoUnqlduJWltbrUHsMjF/NPyprx7IKVK9V2OVkbq26ow9OT6l+L Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10443"; a="275964303" X-IronPort-AV: E=Sophos;i="5.93,247,1654585200"; d="scan'208";a="275964303" Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Aug 2022 19:51:34 -0700 X-IronPort-AV: E=Sophos;i="5.93,247,1654585200"; d="scan'208";a="936054349" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by fmsmga005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Aug 2022 19:51:29 -0700 From: "Huang, Ying" To: Peter Xu Cc: Nadav Amit , Alistair Popple , huang ying , Linux MM , Andrew Morton , LKML , "Sierra Guiza, Alejandro (Alex)" , Felix Kuehling , Jason Gunthorpe , John Hubbard , David Hildenbrand , Ralph Campbell , Matthew Wilcox , Karol Herbst , Lyude Paul , Ben Skeggs , Logan Gunthorpe , paulus@ozlabs.org, linuxppc-dev@lists.ozlabs.org, stable@vger.kernel.org Subject: Re: [PATCH v2 1/2] mm/migrate_device.c: Copy pte dirty bit to page References: <6e77914685ede036c419fa65b6adc27f25a6c3e9.1660635033.git-series.apopple@nvidia.com> <871qtfvdlw.fsf@nvdebian.thelocal> <87o7wjtn2g.fsf@nvdebian.thelocal> <87tu6bbaq7.fsf@yhuang6-desk2.ccr.corp.intel.com> <1D2FB37E-831B-445E-ADDC-C1D3FF0425C1@gmail.com> <87czcyawl6.fsf@yhuang6-desk2.ccr.corp.intel.com> Date: Fri, 19 Aug 2022 10:51:27 +0800 In-Reply-To: (Peter Xu's message of "Thu, 18 Aug 2022 10:44:46 -0400") Message-ID: <874jy9aqts.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1660877496; a=rsa-sha256; cv=none; b=mj/kgILuH2rnHG8Oot4CeRd1KMujm469BYfQn/8EZvlEGE419EHc5WYDZMbrCcoBWoeRVE ZN8CJ1ib7g5SOODk5bDV7bxMyqrJK4lQJv7mlkQ5vvQ1f2FtgeOuLE3b/El8YPy0Hz3WSU YwrWvrL+4JDz28SuTkNrHrMHRvtqiqk= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=nHZxUeJI; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf30.hostedemail.com: domain of ying.huang@intel.com designates 134.134.136.126 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1660877496; h=from:from:sender: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=pStcOB0QkWK/tPWxuZpYhJ7/Bl+mnqTupKxIt1KHY/U=; b=atLv+kFbKvYTPsNS7Y/1diUkyS3x34JE93o6KQRyWpPHwAf+AhKa4glIsNZvpMlnBKgfx6 FowJ9cs4lHNHzShq7Tc9Vqw/cEl69rPyxb20j2mrzoD+7RxM4MPlicYhbjS9a8HfiFvAI7 toBmRi0a7W/CPr46CjjO5UO3kTCrMSg= X-Stat-Signature: p7gmhqbazn7ay9ztfcw5phco6eikhioc X-Rspamd-Queue-Id: D70A380003 Authentication-Results: imf30.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=nHZxUeJI; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf30.hostedemail.com: domain of ying.huang@intel.com designates 134.134.136.126 as permitted sender) smtp.mailfrom=ying.huang@intel.com X-Rspamd-Server: rspam04 X-Rspam-User: X-HE-Tag: 1660877495-206582 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: Peter Xu writes: > On Thu, Aug 18, 2022 at 02:34:45PM +0800, Huang, Ying wrote: >> > In this specific case, the only way to do safe tlb batching in my mind is: >> > >> > pte_offset_map_lock(); >> > arch_enter_lazy_mmu_mode(); >> > // If any pending tlb, do it now >> > if (mm_tlb_flush_pending()) >> > flush_tlb_range(vma, start, end); >> > else >> > flush_tlb_batched_pending(); >> >> I don't think we need the above 4 lines. Because we will flush TLB >> before we access the pages. > > Could you elaborate? As you have said below, we don't use non-present PTEs and flush present PTEs before we access the pages. >> Can you find any issue if we don't use the above 4 lines? > > It seems okay to me to leave stall tlb at least within the scope of this > function. It only collects present ptes and flush propoerly for them. I > don't quickly see any other implications to other not touched ptes - unlike > e.g. mprotect(), there's a strong barrier of not allowing further write > after mprotect() returns. Yes. I think so too. > Still I don't know whether there'll be any side effect of having stall tlbs > in !present ptes because I'm not familiar enough with the private dev swap > migration code. But I think having them will be safe, even if redundant. I don't think it's a good idea to be redundant. That may hide the real issue. Best Regards, Huang, Ying