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 F3C79C47074 for ; Wed, 15 Nov 2023 05:48:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7EA4A6B02D3; Wed, 15 Nov 2023 00:48:58 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 798BF6B0328; Wed, 15 Nov 2023 00:48:58 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 639776B032B; Wed, 15 Nov 2023 00:48:58 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 53CC66B02D3 for ; Wed, 15 Nov 2023 00:48:58 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 2A8A4A032E for ; Wed, 15 Nov 2023 05:48:58 +0000 (UTC) X-FDA: 81459109956.07.E3291DE Received: from invmail4.hynix.com (exvmail4.skhynix.com [166.125.252.92]) by imf02.hostedemail.com (Postfix) with ESMTP id 11FBC80012 for ; Wed, 15 Nov 2023 05:48:54 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=none; spf=pass (imf02.hostedemail.com: domain of byungchul@sk.com designates 166.125.252.92 as permitted sender) smtp.mailfrom=byungchul@sk.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1700027336; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=XSkFHeNgkAsdukNwhoovN4fDCldhNk59AZFwaAYnM7s=; b=65zvHGAFtBnbt3qHteWkvFpwBeeFMt1eCyaz7OgVB24i4wFVWCfr1bZZNeCW7P36ksmuzh KeHVHx/BTlnTVbuj+gZjegXfeYLIbRk4+IeDe02IbsBQVO6nSLhmTqQTuWpr0m0vInFKOP 2pwc0aJVxV+rZGYvMYxPptMDVjA4lB0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1700027336; a=rsa-sha256; cv=none; b=4jO0cyZh1o/FKbCvgT/g9XxBnW0O6qkIZB+JFmg8UD3mFR1GwvtFvOFbS3kvt5It1Q4HCy HqcMrKDzkVRnt9mITkz4sS2y2+oTpyRJGjbnSq9fcH6lKzgCLiM3Y7296jFlfLlx1rXsTd NT3eLelzbWiAaC6LYPiEgu3ysBRUUsk= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=none; spf=pass (imf02.hostedemail.com: domain of byungchul@sk.com designates 166.125.252.92 as permitted sender) smtp.mailfrom=byungchul@sk.com; dmarc=none X-AuditID: a67dfc5b-d85ff70000001748-7f-65545bc4131e Date: Wed, 15 Nov 2023 14:48:46 +0900 From: Byungchul Park To: Nadav Amit Cc: Linux Kernel Mailing List , linux-mm , "kernel_team@skhynix.com" , Andrew Morton , "ying.huang@intel.com" , "xhao@linux.alibaba.com" , "mgorman@techsingularity.net" , "hughd@google.com" , "willy@infradead.org" , "david@redhat.com" , "peterz@infradead.org" , Andy Lutomirski , Thomas Gleixner , "mingo@redhat.com" , "bp@alien8.de" , "dave.hansen@linux.intel.com" Subject: Re: [v3 2/3] mm: Defer TLB flush by keeping both src and dst folios at migration Message-ID: <20231115054846.GA74107@system.software.com> References: <20231030072540.38631-1-byungchul@sk.com> <20231030072540.38631-3-byungchul@sk.com> <63C530D3-3A1D-4BE9-8AA7-EFF5B895BE80@vmware.com> <20231030125129.GD81877@system.software.com> <20231108041208.GA40954@system.software.com> <20231110010201.GA72073@system.software.com> <20231110031347.GA62514@system.software.com> <0EC1ED50-2370-4EA6-9A02-D36E1913224E@vmware.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0EC1ED50-2370-4EA6-9A02-D36E1913224E@vmware.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMIsWRmVeSWpSXmKPExsXC9ZZnke6R6JBUgyctkhZz1q9hs/i84R+b xYsN7YwWX9f/YrZ4+qmPxeLyrjlsFvfW/Ge1OL9rLavFjqX7mCwuHVjAZHF910NGi+O9B5gs Nm+aymzx+wdQ3ZwpVhYnZ01mcRDw+N7ax+KxYFOpx+YVWh6L97xk8ti0qpPNY9OnSewe786d Y/c4MeM3i8fOh5Ye804Gerzfd5XNY+svO4/Pm+Q83s1/yxbAF8Vlk5Kak1mWWqRvl8CVcfby J5aCWRIVl1feZ2xg/CnUxcjJISFgIrFi2xk2GPvCl8tMIDaLgKrE/aZmdhCbTUBd4saNn8wg toiAosSh/fcYQWxmgXesEt8/aYLYwgLREp/2vgKr5xWwkNj+qg+ohotDSGAns8TNKROYIRKC EidnPmGBaFaX+DPvElCcA8iWllj+jwMiLC/RvHU2WDmngJ3Esm+nWUFsUQFliQPbjjOBzJQQ 2MUu8eDmfXaIoyUlDq64wTKBUXAWkhWzkKyYhbBiFpIVCxhZVjEKZeaV5SZm5pjoZVTmZVbo JefnbmIERu2y2j/ROxg/XQg+xCjAwajEw9swMzhViDWxrLgy9xCjBAezkgivuVxIqhBvSmJl VWpRfnxRaU5q8SFGaQ4WJXFeo2/lKUIC6YklqdmpqQWpRTBZJg5OqQbG9Y7Zbfcv/HnibXZc ZPkBz1f1U4QE3oR8kNgTuWKnabAem8a+WTtOtDU1RqVfbzrmKeu4kcmz+OmSx7EltROasmYm ySjW9J0/cljzfAcnn+VhDZ+Eg7oX9y76bnPP5OftB6nvFP/6G5l+v7j1+sVLxjt/K6WUBAbv Nt23bY3E6T2nFZ4+CWbhUGIpzkg01GIuKk4EAH8DeNPWAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFIsWRmVeSWpSXmKPExsXC5WfdrHskOiTV4N5FVos569ewWXze8I/N 4sWGdkaLr+t/MVs8/dTHYnF47klWi8u75rBZ3Fvzn9Xi/K61rBY7lu5jsrh0YAGTxfVdDxkt jvceYLLYvGkqs8XvH0B1c6ZYWZycNZnFQdDje2sfi8eCTaUem1doeSze85LJY9OqTjaPTZ8m sXu8O3eO3ePEjN8sHjsfWnrMOxno8X7fVTaPxS8+MHls/WXn8XmTnMe7+W/ZAvijuGxSUnMy y1KL9O0SuDLOXv7EUjBLouLyyvuMDYw/hboYOTkkBEwkLny5zARiswioStxvamYHsdkE1CVu 3PjJDGKLCChKHNp/jxHEZhZ4xyrx/ZMmiC0sEC3xae8rsHpeAQuJ7a/6gGq4OIQEdjJL3Jwy gRkiIShxcuYTFohmdYk/8y4BxTmAbGmJ5f84IMLyEs1bZ4OVcwrYSSz7dpoVxBYVUJY4sO04 0wRGvllIJs1CMmkWwqRZSCYtYGRZxSiSmVeWm5iZY6pXnJ1RmZdZoZecn7uJERiDy2r/TNzB +OWy+yFGAQ5GJR7ehpnBqUKsiWXFlbmHGCU4mJVEeM3lQlKFeFMSK6tSi/Lji0pzUosPMUpz sCiJ83qFpyYICaQnlqRmp6YWpBbBZJk4OKUaGDuX7xRKqedfHr9I+ejipXtn+BsbrjluyhTp lP/Lz+X1HaWc2zbLrkjy3D5UmZx5Qs2G7R9LBOsvtdW3pn/ITV6y0vFF1gdtXq6pJ/ZpKzc4 X5kWEdSjvcXGrnRh0S1Hg4Ssecz/yzcpL1zh/esrk+dtzebrS3OWSkVdP/vK9vRftUD9E8s2 5iixFGckGmoxFxUnAgC1o6PhvQIAAA== X-CFilter-Loop: Reflected X-Rspamd-Queue-Id: 11FBC80012 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: q5d9txkx6nhnciqyawfr9dhyh4anxt81 X-HE-Tag: 1700027334-639675 X-HE-Meta: U2FsdGVkX18P4DUO1VUJ6hFeV68W878O/GyJ8Nsm4o7DdPPC/1D/CKuDvtSqIgC/Qzrefc0WBIZ/z2FdsSlnmwLoVyvcQKjcrYcRMY3S3YTuJHgpax8e7DJnXeg2vgAQvuNZ/LrJUEGD/v3/BKDtpx64ru/ZVsy8coOHNlSaPrSaggZRC/yXoBgIEMIE1ERpNG1DdXhmT9+Rs1L8wIkDMha1trLnIXcqsogzLfCiUUuCbJtilwr+jRgEMB+WRmqiCMASEt+yOp2k2I8CIX0Uv+x81ua0FIY7i5J3QstAukuTUNYg34zoKaQiP2CTgmC7ps6z9IDSW4JDhDoHXPi9G0/SQ1eFAMd1kgdcDIVS38giHdFvwBpmjuwCpYoZg3/vqZUXObh2OlwZRWEmcI3zScnSQwRzU/ZhvDOmfODdvj9ieUAx9unslF0fnK3Lw/j5/tv8nllcvhPB0Tqf7v93E+lKS7ZOo7yU0DVFck9urSDdmLuiPfvaDBJ9fqN3mgiMKPSqW09VTvkDwT75jR8Qn1SjkupgnSJ5NR32p9kIxALNIMTDQtOiE3iULcD9x9XqFt4lMMK+WmKq8bTrJQ1cPuAWaW6rXUvT9NJy+URM7ivC5YgWZTt8x9znAAUVVJpL3YKP4gCA0GpxcjXqokiXoTS+z/n0GISTc6OQ6h3d/YbQvTsNMj74BEdSNTE8CR/mVIEQRiSy1hsxDazv/zn06WjI64fCWLMcYjh9NYj+NXOKMFJMHmwILnMjogvWxriabUnF5RIcowzBNBAENHa0e5MChzPLYVWO+fiBybPiupieK5QCnJENX8arNd9ZKK7RHLM/SFIMG7MmKBOU44v73MKUc/jGi5Zu3DutXBgVk5fnFUAojRW3pjGyi4cQMGgcy5+gdeHSNNTl2fKPb5vX6H/DyHgTv4ATZTS8tx2dMcMOgWGRl57Mn12GLwkX9hQCAqofxqA4pToS/p+awqV qCShEA4u 7POAwzRxf92iQaUsSuAE22ZbQWzme2EO95mNX+0RG4zAa8/wJRwNF+huqOGTKvqflnh5lUTHAStdT1hU= 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: List-Subscribe: List-Unsubscribe: On Fri, Nov 10, 2023 at 10:18:06PM +0000, Nadav Amit wrote: > > On Nov 10, 2023, at 5:13 AM, Byungchul Park wrote: > > > > > >> Here, > >> > >> mprotect() > >> do_mprotect_pkey() > >> tlb_finish_mmu() > >> tlb_flush_mmu() > >> > >> I thought TLB flush for mprotect() is performed by tlb_flush_mmu() so > >> any cached TLB entries on other CPUs can have chance to update. Could > >> you correct me if I get it wrong? Thanks. > > > > I guess you tried to inform me that x86 mmu automatically keeps the > > consistancy based on cached TLB entries. Right? If yes, I should do > > something on that path. If not, it's not problematic. Thoughts? > > Perhaps I lost something in this whole scheme. Overall, I find it overly > complicated and somewhat hard to follow. > > Ideally, a solution should reduce the number of TLB flushing mechanisms > and not introduce yet another one that would further increase the already > high complexity. > > Anyhow, I a bit convoluted 2 scenarios, and I’m not sure whether they > are a potential problem. > > (1) Assume there is a RO page migration and you skipped a TLB flush. > Then you set a RO PTE entry for that page. Afterwards, you have mprotect() > that updates the PTE for that page to be RW. > > Now, tlb_finish_mmu() will do a TLB flush eventually in the mprotect() > flow, but until it is done, you might have one CPU have RO pointing to > the source page (no TLB flush, right?) and another having RW access Is it possible for there to be another having RW access even before mprotect() is done? > that were loaded from the updated PTE. Did I miss a TLB flush that > should take place beforehand? > > > (2) Indeed we encountered many problems when TLB flushing decisions > are based on PTEs that are read from the page-tables and those do > not reflect the values that are held in the TLBs. Do you have any example to help me understand what you mean? > Overall, I think that a solution is to consolidate the TLB batching > mechanisms and hold per a group of PTEs (e.g., 512 PTEs held in one > page-table) the deferred TLB flush generation. Track the “done” TLB > flush generation, if the deferred is greater than the “done”, perform > a TLB flush. > > This scheme is a bit similar to what you were doing, but more general, > and easier to follow. I think that its value might be more in simplifying > the code and reasoning than just performance. Worth noting that, at the beginning, I tried to reduce TLB flushes by: 1. deferring and performing TLB flushes needed in a batch, 2. skipping some TLB flushes that have already been done. However, I gave up the 2nd optimization to keep only architecture independent code in the patch set. So the current migrc version couldn't skip TLB flushes but does only deferring and batching TLB flushes until it's inevitable. To cut a long story short, migrc let any other TLB flushes go performed as is, *except* a special case e.i. RO mapped folios, during migration. Byungchul