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 F284DC25B7E for ; Tue, 4 Jun 2024 08:18:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 645A96B0096; Tue, 4 Jun 2024 04:18:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5F5446B0099; Tue, 4 Jun 2024 04:18:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4BCB56B009A; Tue, 4 Jun 2024 04:18:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 2EEA56B0096 for ; Tue, 4 Jun 2024 04:18:51 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id D2342140AA3 for ; Tue, 4 Jun 2024 08:18:50 +0000 (UTC) X-FDA: 82192505220.03.8FE0017 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.10]) by imf16.hostedemail.com (Postfix) with ESMTP id 8DBA3180018 for ; Tue, 4 Jun 2024 08:18:47 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b="dCf78W1/"; spf=pass (imf16.hostedemail.com: domain of ying.huang@intel.com designates 192.198.163.10 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1717489128; 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=5Juv8aSLdzWCWByHFdxbm0E3cWB4jktVxnyQJMvb9DQ=; b=EB6nYjhRpzMaQ+wBO2An6cyGtZTKRY6ez4lTVP9TBP3te7hdqcLFwBjLdy1YryDKtOmUxE T8Xci/BpXFod6RB70FWPxz+sTT3Eg/aWNs0gNRdAf0XUoWucBiCE/Sqrqus8lg2LQxiTqW P/wGGilN4ypIyiZqCE7WYh4P0rEbyos= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b="dCf78W1/"; spf=pass (imf16.hostedemail.com: domain of ying.huang@intel.com designates 192.198.163.10 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1717489128; a=rsa-sha256; cv=none; b=cjPpLa7v2M/84Y/JbLZdp6kjjX3OIHNifdSi4X0HqrlCZI9l/xnzgeHByfJZhC62foaLaQ KmfDiQ+XEcTWYrcr/0my+5kKBY+x57jzfKQ3GepAmZX/kc9vj5iA2PXO1EJdGlhoEtfty3 IWvR9VTOeRmYDnNMWwOFiCmfYjISvgI= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1717489128; x=1749025128; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=t4AlPKcMOvF+J0KAl9cz4z7x0CWBkr/MlJ8H27UTrHo=; b=dCf78W1/AKv2WrHx4Q/RUiAV7AlzNbayO2ODWaLXYpvQkMohs9Usy2n1 FpS9G70Nfu60cES7fUrR4kB/r2AS7td/hjoWiV639iHkObA/HdjpxhrJ3 TqH8sF9jD7jOz37K9gOdfM1iQvXLk38qtroSBOstli5ZCaEsC+1yo7zNo +WDtkK2r2C1lNQ7Ar0jQTFcmq0Ml8HRTGX5XlxUjxXHTHmHPqwbFaauDT rxsmBdsvY1GZaEJNPjtx5BpCqDInmYoeSjcwfsyhiBZ1/j9aMEXxl7fOV B2cPy9OZSTLMhLWJogv4OBsnT2hVUddYONv8E5SoDRkd5SpqxgfCWegcP w==; X-CSE-ConnectionGUID: oxhQ2L+kR8a+yQvaf7uorg== X-CSE-MsgGUID: o95fxBFXSgmjDqNhW9V1fw== X-IronPort-AV: E=McAfee;i="6600,9927,11092"; a="25417175" X-IronPort-AV: E=Sophos;i="6.08,213,1712646000"; d="scan'208";a="25417175" Received: from fmviesa009.fm.intel.com ([10.60.135.149]) by fmvoesa104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Jun 2024 01:18:45 -0700 X-CSE-ConnectionGUID: 1zgcUipQRbSslbX3cwqIaQ== X-CSE-MsgGUID: iF7ryx1fQ/KGN7P9cTR90Q== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.08,213,1712646000"; d="scan'208";a="37286242" Received: from unknown (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by fmviesa009-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Jun 2024 01:18:41 -0700 From: "Huang, Ying" To: David Hildenbrand Cc: Matthew Wilcox , Dave Hansen , Byungchul Park , Byungchul Park , linux-kernel@vger.kernel.org, linux-mm@kvack.org, kernel_team@skhynix.com, akpm@linux-foundation.org, vernhao@tencent.com, mgorman@techsingularity.net, hughd@google.com, peterz@infradead.org, luto@kernel.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, rjgolo@gmail.com Subject: Re: [PATCH v11 09/12] mm: implement LUF(Lazy Unmap Flush) defering tlb flush when folios get unmapped In-Reply-To: <24daabde-300e-4a28-9a1c-9e406b087195@redhat.com> (David Hildenbrand's message of "Mon, 3 Jun 2024 20:00:52 +0200") References: <20240531092001.30428-1-byungchul@sk.com> <20240531092001.30428-10-byungchul@sk.com> <26dc4594-430b-483c-a26c-7e68bade74b0@redhat.com> <20240603093505.GA12549@system.software.com> <35866f91-7d96-462a-aa0a-ac8a6b8cbcf8@redhat.com> <196481bb-b86d-4959-b69b-21fda4daae77@intel.com> <24daabde-300e-4a28-9a1c-9e406b087195@redhat.com> Date: Tue, 04 Jun 2024 16:16:49 +0800 Message-ID: <877cf5ceby.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 8DBA3180018 X-Stat-Signature: ahr8jjdqsh4fk4mig6wd8mcdqrnmfqsj X-HE-Tag: 1717489127-723110 X-HE-Meta: U2FsdGVkX18sAdyVsxWBfKJPlgV8j7BMW32FtEtylfvnt6EEaDMXcQGnWBILNpcEuNA1tbS4f3t2N1mouQ4bIerYtKXsJKtstVlV5Hq/SZPjR76kkIq7CE9l1fjyKQMhXnszgB6qSah9xCNB1r3w5rlwEmv45f9O05b8sk+ztUZCWB9QoRQHpaIUAxgUslKpx3Fqpn+oko4nqqccD6sK+FXZRJXPTZU8Ymp1w+AhpqpY6+htcag1fTrlmr3yi3qRSigCFKMOF87tsqbOcpRNeHPP7XmLgX7Nwy5NXLM1qN0j/VEUwd0JV1KhcHDqfg01lkEiz+rwXYGgt4DRQlUN+U9VkQ6YxXrSnV19LYzOQMxZVrR9AFYAS0rulTUVzrdToAeYpo0ZRICtAfkkPLRvzqDGZkMT8a63DzNhT8HLVY6KVhBq5ty+5FqmIrQLptL7upgLJ+mynrBsDAVwSBvwIZViDeXv5dui7u+ZSiGYQOKfzRWRQ60mVBHYL27Lq9ebX066D+NnZ42NZ/eAhBK8DGNcCLovqQdfWoK3dhJtxxoIPh8hA8t6idqfwMrv/Ef9Kg2C/zy1zQvbQICvyThbcO2oS/WjaCEO3m/L09AOGx/tXz6e29N79vC80kUXa8HYhL9Sc7MiTZGcx0DDbWQJ+7MpcCGSK44J3tac/GRv+NuMpDLTdZ/srPyEY9qbQL3F5LoT0VtMeWR7YC21f4ZKhJSsYTQjIRQiJZU1HkCbkdFXQlk+OSmrG4b4djgy88K9R+mE4PfH31h4TLxpfR/0sl9WKLkHrxvLGmtDGxgK7QjC4oyHsXTOXrtfqg7Y/6eyh0fPA4qe9+/7fhj5UtadeMLySQvjhXz1LHu5sBDWcS5j4mR26CckWaubA2W+xsPTgBvNt7AutjcHNJDvZVM3cUuTMLyBMj/KUjyNV/G93F3FLsBgEZ9iK5eQyVN2VOchwRKoKJ0FMCkE0BZfAej 59KTCrcN 4JjQQpbWL3Un/a6xrx6qmh7hTuGa0IJG1iAITCxQJTY+aeFtPoTYo/9fWWCRSZK8ws0HVfSOOrIw0gXQUstgiw5GbqqSEw6v2RG4oDp+6jTPTTyrj4itW3DOErgXuDne3PnU94nzWA2ASNbYIQu9wNDW/NP72HmvrgTVB3lUdqNpyyIv9d2KlFZ2+8842M7xcD8fcKzV9h1/39WEyHaksm+HWiQWtx4sr76zMJHwIQRlEeueDVF50oa0hIA== 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: David Hildenbrand writes: > On 03.06.24 19:01, Matthew Wilcox wrote: >> On Mon, Jun 03, 2024 at 09:37:46AM -0700, Dave Hansen wrote: >>> Yeah, we'd need some equivalent of a PTE marker, but for the page cache. >>> Presumably some xa_value() that means a reader has to go do a >>> luf_flush() before going any farther. >> I can allocate one for that. We've got something like 1000 >> currently >> unused values which can't be mistaken for anything else. > > I'm curious when to set that, though. > > While migrating/reclaiming, when unmapping the folio from the page > tables, the folio is still valid in the page cache. So at the point in > time of unmapping from one process, we cannot simply replace the folio > in the page cache by some other value -- I think. > > Maybe it's all easier than I think. IIUC, we need to held folio lock before replacing the folio in the page cache. In page_cache_delete(), folio_test_locked() is checked. And, we will lock the folio before writing to it via write syscall. So, it's safe to defer TLB flushing until we unlock the folio. -- Best Regards, Huang, Ying