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 6F669C25B74 for ; Fri, 31 May 2024 02:21:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 04AA46B0088; Thu, 30 May 2024 22:21:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F3D1D6B0089; Thu, 30 May 2024 22:21:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E04726B008C; Thu, 30 May 2024 22:21:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id C2CA66B0088 for ; Thu, 30 May 2024 22:21:08 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 5A690A2986 for ; Fri, 31 May 2024 02:21:08 +0000 (UTC) X-FDA: 82177088616.18.462164A Received: from invmail4.hynix.com (exvmail4.hynix.com [166.125.252.92]) by imf11.hostedemail.com (Postfix) with ESMTP id ABC434000A for ; Fri, 31 May 2024 02:21:05 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=none; spf=pass (imf11.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=1717122066; 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; bh=2VkArMcI4hlBgAFsf+VnFlBTa6HXRg3vK9nk89KGY5o=; b=OtD67QsLPgNYYF4kgRgAURRbz4bVtyMqLHUewqcFW2GfHeKdxxY7FJIeEmwsL0s5sCdUlf OxehdlfUITEdJ4X4ECG5MUm3zF9tC1v7M8Cx89nrYGGNSWsV2p9aPoFgCNYn7KVMUVcDOi +XFVyGteSGaPUzPjj9pr3CPb4icX9eM= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1717122066; a=rsa-sha256; cv=none; b=U8AxhYKugCeE7hDxadg0f4P0CZDxJs6zvi/qw6pEur9vNvhBVcU5VuvuxQvqxmYTVobRVe itJnIW2eX2xR4GXQjjGUk5CgM5fr+dsRg6TxJFZK6YCHUdtjPFC6yycYA4YJndrdXVgnZs KxNCeFZbdj57S5sr4nUHzaKVIZfRoD8= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=none; spf=pass (imf11.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-12-6659340faa12 Date: Fri, 31 May 2024 11:20:57 +0900 From: Byungchul Park To: "Huang, Ying" Cc: Dave Hansen , 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, willy@infradead.org, david@redhat.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 v10 00/12] LUF(Lazy Unmap Flush) reducing tlb numbers over 90% Message-ID: <20240531022057.GA80728@system.software.com> References: <8734q46jc8.fsf@yhuang6-desk2.ccr.corp.intel.com> <44e4f2fd-e76e-445d-b618-17a6ec692812@intel.com> <20240529050046.GB20307@system.software.com> <961f9533-1e0c-416c-b6b0-d46b97127de2@intel.com> <20240530005026.GA47476@system.software.com> <87a5k814tq.fsf@yhuang6-desk2.ccr.corp.intel.com> <20240530071847.GA15344@system.software.com> <871q5j1zdf.fsf@yhuang6-desk2.ccr.corp.intel.com> <20240530093306.GA35610@system.software.com> <87wmnazrcy.fsf@yhuang6-desk2.ccr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87wmnazrcy.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrIIsWRmVeSWpSXmKPExsXC9ZZnoS6/SWSawa9Ofos569ewWXze8I/N 4tPLB4wWLza0M1p8Xf+L2eLppz4Wi8u75rBZ3Fvzn9Xi/K61rBY7lu5jsrh0YAGTxfHeA0wW 8+99ZrPYvGkqs8XxKVMZLX7/ACo+OWsyi4Ogx/fWPhaPnbPusnss2FTqsXmFlsfiPS+ZPDat 6mTz2PRpErvHu3Pn2D1OzPjN4jHvZKDH+31X2Ty2/rLzaJx6jc3j8ya5AL4oLpuU1JzMstQi fbsErozZJ7cxFpzQrHh8bDF7A2OrQhcjJ4eEgIlE2/stTDD26cNf2boYOThYBFQldi5QAwmz CahL3LjxkxnEFhHQkPi0cDl7FyMXB7NAH7PEmsWHGEESwgIhEtM+rAGbwytgIbHi8FR2EFtI 4DezxNQ3iRBxQYmTM5+wgNjMAloSN/69ZALZxSwgLbH8HwdImFPATmLn6VVgraICyhIHth1n AtklIbCNXeLzhF3MEHdKShxccYNlAqPALCRjZyEZOwth7AJG5lWMQpl5ZbmJmTkmehmVeZkV esn5uZsYgRG5rPZP9A7GTxeCDzEKcDAq8fAGVESkCbEmlhVX5h5ilOBgVhLh/ZUOFOJNSays Si3Kjy8qzUktPsQozcGiJM5r9K08RUggPbEkNTs1tSC1CCbLxMEp1cBYyvhvWkJmzAGFN1Mm 1N122rXk0k+5tGPX51y5f8+oZcnzf+yZTVn3trxh371dYPZa6Z/9/b+Nf/udt1999s0H+Rtf nT83vt/ddLzzwCXH/Q6hpyYuK/rS+rHpglfynq+CBXHSd3LvFTCXVkhu2PzjW9vqbcYsBSdP /Jl6fIXw8b0dShEHltToOSixFGckGmoxFxUnAgCQkp0QxAIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBIsWRmVeSWpSXmKPExsXC5WfdrMtvEplmsKCP0WLO+jVsFp83/GOz +PTyAaPFiw3tjBZf1/9itnj6qY/F4vDck6wWl3fNYbO4t+Y/q8X5XWtZLXYs3cdkcenAAiaL 470HmCzm3/vMZrF501Rmi+NTpjJa/P4BVHxy1mQWByGP7619LB47Z91l91iwqdRj8wotj8V7 XjJ5bFrVyeax6dMkdo93586xe5yY8ZvFY97JQI/3+66yeSx+8YHJY+svO4/GqdfYPD5vkgvg j+KySUnNySxLLdK3S+DKmH1yG2PBCc2Kx8cWszcwtip0MXJySAiYSJw+/JWti5GDg0VAVWLn AjWQMJuAusSNGz+ZQWwRAQ2JTwuXs3cxcnEwC/QxS6xZfIgRJCEsECIx7cMaJhCbV8BCYsXh qewgtpDAb2aJqW8SIeKCEidnPmEBsZkFtCRu/HvJBLKLWUBaYvk/DpAwp4CdxM7Tq8BaRQWU JQ5sO840gZF3FpLuWUi6ZyF0L2BkXsUokplXlpuYmWOqV5ydUZmXWaGXnJ+7iREYX8tq/0zc wfjlsvshRgEORiUe3oCKiDQh1sSy4srcQ4wSHMxKIry/0oFCvCmJlVWpRfnxRaU5qcWHGKU5 WJTEeb3CUxOEBNITS1KzU1MLUotgskwcnFINjIwJO7iUGJM/63AL2x3wvV2gJz6Bd59u08UT H5jtTKbvN3KN3WSj+sYu+9FObUklJ8bJH82ddJTvlBtu9FJwy921T7P1gdnLOzu4/yw22JCp sdNX+3FQN8spb91FJUv/dvLN0NproaxjmLg7+eDxed+lvostjWhsmfr3fNzUvPM+2y+8/Lo6 V4mlOCPRUIu5qDgRAOveGQWrAgAA X-CFilter-Loop: Reflected X-Rspam-User: X-Stat-Signature: rmfd5ufyh3sbp9guqnb34makq17apndi X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: ABC434000A X-HE-Tag: 1717122065-338816 X-HE-Meta: U2FsdGVkX1/Kpc5xf2tSvdtdVrjnYL41gmkyFmiQf2wA3U5fEim2zkByE+FP30zlLkvCPDyYiumZjLHMxHnQu1S5ohHb4UzIvQ0vGh1Mgo/y377bXW3OGDb8/IVtWdroQsCDFa8YBtgBhsRfDKb6cWCJt5NgWUPOlTatPkso3kHbnUsToQVCgH3ja79D9+bgu+iW6AehfEsJMnT77BpHeOjdNgPYaZuDPnRUzDbjHIw+NbOie+5rYQTM3nWfEPP+73Fn0eku3Ctr6dxcvTQcbVupsIQhIe2Fctjjj7jzj7uwzypfwsRTZ/3F6H+SLW/ZDOcm4M49lYKPmCq7DQ3QtLjZN9AR2m+uggWBokONl+8VdTdMmHG6LtQNkqwGm7WeHuMAwJliQUIJ6hHNXDgq4rnKebVPhA/RkZHW3ggKNwET5QzZ1+EBB7XbD8ZbcXrBJFrBSaLC057nTC/YQ0BXIe5YT/Ys5aZP40DrwN8HpVrFEZ5c5fr3AsRsVVfo9bzKJJwb4dzQpKPybdfWuiIozNApYiEvnScyGW8kh+n1O1vFH2Z4V/zEUJe2yzLpW6G8p/khfeCQT1NuEvYiNTJPYqLFgjcR9j/kewX8ngI1Sol7kXwm5HUocrbGkLcnuo9wjqIhtzBjQfPCUS78nTDBXzkjX5d9JBZaayxx3XWzuZKbdIXguTk/V5hMaapCF4kMN7RSG9sgLxLWUv5kMa7nte1g1d/KqyEBs6dZqU3BUHOnX2XuCZm8Pl6iSOj+P0jUiyZ0HcxkGW1PKMW2ppqy+3Fzs00qmRsYIh2YtJvBOBEDwaAIPBZi5zbL5+AMoVc9alQ/9+PXSc1L8FgPg6H4a6emHBtZ+eKSVURcmeNhM1g/KQ+pGmVoXc0deYhTfexzB1nsMrgNzsV7An8iPgn0E+INkz6hu0+XuEA1tbcHvCr82cLhvZINQlyd7XauARkKlLrw4ScRS5cJdw9231s i4TfX4jp 8Gf0a0Klt+6jvaZYITbR6BucyGPX9qp3HM+LAWyJ5Ps0W5aFkl6FA5GzbBxRuDdQXAZv3F4EWmEmtRcm9xwBnokl/YRqLjjWHAtIEJmMJp+8kyeXVdWeDTxTguw== 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, May 31, 2024 at 09:45:33AM +0800, Huang, Ying wrote: > Byungchul Park writes: > > > On Thu, May 30, 2024 at 04:24:12PM +0800, Huang, Ying wrote: > >> Byungchul Park writes: > >> > >> > On Thu, May 30, 2024 at 09:11:45AM +0800, Huang, Ying wrote: > >> >> Byungchul Park writes: > >> >> > >> >> > On Wed, May 29, 2024 at 09:41:22AM -0700, Dave Hansen wrote: > >> >> >> On 5/28/24 22:00, Byungchul Park wrote: > >> >> >> > All the code updating ptes already performs TLB flush needed in a safe > >> >> >> > way if it's inevitable e.g. munmap. LUF which controls when to flush in > >> >> >> > a higer level than arch code, just leaves stale ro tlb entries that are > >> >> >> > currently supposed to be in use. Could you give a scenario that you are > >> >> >> > concering? > >> >> >> > >> >> >> Let's go back this scenario: > >> >> >> > >> >> >> fd = open("/some/file", O_RDONLY); > >> >> >> ptr1 = mmap(-1, size, PROT_READ, ..., fd, ...); > >> >> >> foo1 = *ptr1; > >> >> >> > >> >> >> There's a read-only PTE at 'ptr1'. Right? The page being pointed to is > >> >> >> eligible for LUF via the try_to_unmap() paths. In other words, the page > >> >> >> might be reclaimed at any time. If it is reclaimed, the PTE will be > >> >> >> cleared. > >> >> >> > >> >> >> Then, the user might do: > >> >> >> > >> >> >> munmap(ptr1, PAGE_SIZE); > >> >> >> > >> >> >> Which will _eventually_ wind up in the zap_pte_range() loop. But that > >> >> >> loop will only see pte_none(). It doesn't do _anything_ to the 'struct > >> >> >> mmu_gather'. > >> >> >> > >> >> >> The munmap() then lands in tlb_flush_mmu_tlbonly() where it looks at the > >> >> >> 'struct mmu_gather': > >> >> >> > >> >> >> if (!(tlb->freed_tables || tlb->cleared_ptes || > >> >> >> tlb->cleared_pmds || tlb->cleared_puds || > >> >> >> tlb->cleared_p4ds)) > >> >> >> return; > >> >> >> > >> >> >> But since there were no cleared PTEs (or anything else) during the > >> >> >> unmap, this just returns and doesn't flush the TLB. > >> >> >> > >> >> >> We now have an address space with a stale TLB entry at 'ptr1' and not > >> >> >> even a VMA there. There's nothing to stop a new VMA from going in, > >> >> >> installing a *new* PTE, but getting data from the stale TLB entry that > >> >> >> still hasn't been flushed. > >> >> > > >> >> > Thank you for the explanation. I got you. I think I could handle the > >> >> > case through a new flag in vma or something indicating LUF has deferred > >> >> > necessary TLB flush for it during unmapping so that mmu_gather mechanism > >> >> > can be aware of it. Of course, the performance change should be checked > >> >> > again. Thoughts? > >> >> > >> >> I suggest you to start with the simple case. That is, only support page > >> >> reclaiming and migration. A TLB flushing can be enforced during unmap > >> >> with something similar as flush_tlb_batched_pending(). > >> > > >> > While reading flush_tlb_batched_pending(mm), I found it already performs > >> > TLB flush for the target mm, if set_tlb_ubc_flush_pending(mm) has been > >> > hit at least once since the last flush_tlb_batched_pending(mm). > >> > > >> > Since LUF also relies on set_tlb_ubc_flush_pending(mm), it's going to > >> > perform TLB flush required, in flush_tlb_batched_pending(mm) during > >> > munmap(). So it looks safe to me with regard to munmap() already. > >> > > >> > Is there something that I'm missing? > >> > > >> > JFYI, regarding to mmap(), I have reworked on fault handler to give up > >> > luf when needed in a better way. > >> > >> If TLB flush is always enforced during munmap(), then your solution can > >> only avoid TLB flushing for page reclaiming and migration, not unmap. > > > > I'm not sure if I understand what you meant. Could you explain it in > > more detail? > > > > LUF works for only *unmapping* that happens during page reclaiming and > > migration. Other unmappings than page reclaiming and migration are not > > what LUF works for. That's why I thought flush_tlb_batched_pending() > > could handle the pending tlb flushes in the case. > > > > It'd be appreciated if you explain what you meant more. > > > > In the following email, you have claimed that LUF can avoid TLB flushing > for munmap()/mmap(). My bad. Sorry for that confusing expression. "give up LUF at mmap()" doesn't mean giving up applying LUF to mmap(). "give up LUF at mmap()" means giving up the pending that has been induced by LUF, in other words, giving up the benefit by LUF because we are going through mmap() / munmap(). I will be more careful in expressing these things. > https://lore.kernel.org/linux-mm/20240527015732.GA61604@system.software.com/ > > Now, you said it can only avoid TLB flushing for page reclaiming and > migration. This is true. Byungchul > So, to avoid confusion, I suggest you to send out a new series and make > it explicit that it can only optimize page reclaiming and migration, but > not munmap(). And it would be good too to add some words about how it > interact with other TLB flushing mechanisms. > > -- > Best Regards, > Huang, Ying