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 46A32C021B2 for ; Thu, 20 Feb 2025 23:37:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D3F336B00BA; Thu, 20 Feb 2025 18:37:22 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CC77D6B00BC; Thu, 20 Feb 2025 18:37:22 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B411F280001; Thu, 20 Feb 2025 18:37:22 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 925B76B00BA for ; Thu, 20 Feb 2025 18:37:22 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 32B32A6CD5 for ; Thu, 20 Feb 2025 23:37:22 +0000 (UTC) X-FDA: 83141936724.26.BE4A815 Received: from invmail4.hynix.com (exvmail4.hynix.com [166.125.252.92]) by imf15.hostedemail.com (Postfix) with ESMTP id 92A57A0002 for ; Thu, 20 Feb 2025 23:37:19 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf15.hostedemail.com: domain of byungchul@sk.com designates 166.125.252.92 as permitted sender) smtp.mailfrom=byungchul@sk.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740094640; a=rsa-sha256; cv=none; b=rhi87N7bnys5lrdPKajcH1UVWCL0lBNF3r3BVLIswfRyiZqf0jUf9Or/0NF4Pl00igasFl jOT9ZiI4p5cjiQM16pwUVOlhDDN+AQr60qf6HoHs3gUIaJ6m4b4wScQe964oxtIJ1xXhfJ GLLN5otDdvnUXMKOWl4qI6bo7M1mctI= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf15.hostedemail.com: domain of byungchul@sk.com designates 166.125.252.92 as permitted sender) smtp.mailfrom=byungchul@sk.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740094640; 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=rxtHp08VSCs2KDJHC1QodfYasy1BgHaYdE5C3pSTLnM=; b=0V8rr7NoZ+dmKEWN9OsPpzNkx57EWjQkDihrl71q+29So77iM8mhqxhK8eXzgYTbd5vL3K KfiPiXqlEbnyD7URatbPI27lvQPVpJvbh3WNokz6IajlZCWMMo785bb/iLMo3WPsMRk2mw uoy3loUpBL0XHIDpvhAKku4zVQbbELE= X-AuditID: a67dfc5b-3c9ff7000001d7ae-d1-67b7bcabd130 Date: Fri, 21 Feb 2025 08:37:10 +0900 From: Byungchul Park To: Vlastimil Babka Cc: Dave Hansen , linux-kernel@vger.kernel.org, linux-mm@kvack.org, kernel_team@skhynix.com, akpm@linux-foundation.org, ying.huang@intel.com, 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: [RFC PATCH v12 00/26] LUF(Lazy Unmap Flush) reducing tlb numbers over 90% Message-ID: <20250220233710.GB39373@system.software.com> References: <20250220052027.58847-1-byungchul@sk.com> <8accbd91-ca59-43f8-b190-7e1ac3df5e11@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLIsWRmVeSWpSXmKPExsXC9ZZnke7qPdvTDWbNMbKYs34Nm8XnDf/Y LD69fMBo8WJDO6PF1/W/mC2efupjsbi8aw6bxb01/1ktzu9ay2qxY+k+JotLBxYwWRzvPcBk Mf/eZzaLzZumMlvMbuxjtDg+ZSqjxe8fQB0nZ01mcRDy+N7ax+Kxc9Zddo8Fm0o9Nq/Q8li8 5yWTx6ZVnWwemz5NYvd4d+4cu8eJGb9ZPOadDPR4v+8qm8eZBUfYPbb+svNonHqNzePzJrkA /igum5TUnMyy1CJ9uwSujI3PZ7EX9AtVbN78nbGBcRFfFyMnh4SAiUR72zo2GPve+4nMIDaL gKrE5UvdYDabgLrEjRs/wWwRARWJRxuOsnYxcnEwCyxhlljx7xkTSEJYIELiyaETYDavgIVE +/7X7CBFQgIzGSUmLjrAApEQlDg58wmYzSygJXHj30ugBg4gW1pi+T8OkDCngLVE/7J9jCC2 qICyxIFtx5lA5kgIHGOXaLvziAXiUkmJgytusExgFJiFZOwsJGNnIYxdwMi8ilEoM68sNzEz x0QvozIvs0IvOT93EyMwUpfV/onewfjpQvAhRgEORiUe3gTT7elCrIllxZW5hxglOJiVRHjb 6rekC/GmJFZWpRblxxeV5qQWH2KU5mBREuc1+laeIiSQnliSmp2aWpBaBJNl4uCUamCcNK/k reHL/EAvwwVZD8VmLnY6H/n2LqtshVrqUlGmFOH0/69slnzgOdbLLtmYnfXj9/W4S23RWmbh 1+SD5fsPR5Q1Tnrn9L5lXtDZnh8zY59v85Kd/+XmRb7zn15Kt2wJ6/ySIifc0Jzsk7NylU7Z 3pK3Sxk32Bw3XFFWv+0Xd8iSi1vNGC8osRRnJBpqMRcVJwIAXw4c7tACAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCIsWRmVeSWpSXmKPExsXC5WfdrLt6z/Z0gynNahZz1q9hs/i84R+b xaeXDxgtXmxoZ7T4uv4Xs8XTT30sFofnnmS1uLxrDpvFvTX/WS3O71rLarFj6T4mi0sHFjBZ HO89wGQx/95nNovNm6YyW8xu7GO0OD5lKqPF7x9AHSdnTWZxEPb43trH4rFz1l12jwWbSj02 r9DyWLznJZPHplWdbB6bPk1i93h37hy7x4kZv1k85p0M9Hi/7yqbx+IXH5g8ziw4wu6x9Zed R+PUa2wenzfJBQhEcdmkpOZklqUW6dslcGVsfD6LvaBfqGLz5u+MDYyL+LoYOTkkBEwk7r2f yAxiswioSly+1A1mswmoS9y48RPMFhFQkXi04ShrFyMXB7PAEmaJFf+eMYEkhAUiJJ4cOgFm 8wpYSLTvf80OUiQkMJNRYuKiAywQCUGJkzOfgNnMAloSN/69BGrgALKlJZb/4wAJcwpYS/Qv 28cIYosKKEsc2HacaQIj7ywk3bOQdM9C6F7AyLyKUSQzryw3MTPHVK84O6MyL7NCLzk/dxMj MO6W1f6ZuIPxy2X3Q4wCHIxKPLwJptvThVgTy4orcw8xSnAwK4nwttVvSRfiTUmsrEotyo8v Ks1JLT7EKM3BoiTO6xWemiAkkJ5YkpqdmlqQWgSTZeLglGpgdN7l1f3pqNMk5mtbg9bO+X3+ 1nQfwTVLFyjPkD9xf8+OLU80ZjW+/r7MyXS1GH/mue99wvofZyrZbl66c9+8FZ++Jkw/MeXn oqx9RVwyzRYloRLXz0bPUmFR2nF7guknWfdVQQveC6zxEt4m5ZCa9PKZ254V/851Twi922vY JHfwzx2Jp+9W7LiuxFKckWioxVxUnAgA6om6xLcCAAA= X-CFilter-Loop: Reflected X-Rspamd-Queue-Id: 92A57A0002 X-Stat-Signature: umtn48mz5txn58aypmehmxd4erzib17q X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1740094639-504995 X-HE-Meta: U2FsdGVkX1+Ch5KrnI9F39Zb7cR2xIxyO7AcQDx0osMIsyyH1y9PS28R6I33z40hCvFzoIAYUCrmGPSjLuJNY3JNGTVxIgqNe/wRXoiDAhg5ZycYV1lJtcg70HXNSAjX5L8r62IJ+X+dAc+HOvqpjdeSN+yCoqGqogvfFnm/QHvQcHmLzxz4U+R0GdacvNDNqmjpX+7VHtsrxFs0qPMUu9iz7clnxMin2HqkHn5yuKsL6N169mnKJjDxvmvlBGHp/TEtrAGO9GwU7YLfdUnlzpy9UlhRMEtLOfVGXZ9rSfUKQYFLiBd4jZAUCb7unlAumGah9+Mrhs4DSFwvP4k7Hy1iget9qkagEjgOMV1HFcRulUaiWs89/gspplJdRNfSieMb2DqTeGt4ThTdjs5YFsApU9OyErGlhSzIxLEWT4KWH2ctzugGVH++gFnmAx81+KUoOnTBKe+k0Xov0iIyfuJl2QVc6O/YAS+EaFsGd0vN/5tOUZecs3OpAi3BTjmEnce4jzLLFrM5FJaCLJUkdXd0/IFictgwBtOHEgKeKaqKhQzOlU5syImRP9ioLP1ocHIc1yBr/+Gi8ynOJFfMN2by7oQWhbSaoC558jrfEsCYKEL8RvrTO/VjDjhLy1ZtPreK8vuPZ/Ukp8NJccsFdBJ78zkr7RZ6JrVcnqA8M9TSw9CujhiTMt5TA2+IZUAueFGq7vCzDBZGfFb5CpE3HnTK4g95yP7AN9hggwCbrUGCYPH6z9CB9vtrChONBUuLP6/WZ/m7av9zQg3xTSNivwkJwOVsQS004lpiUk1BzO6T2dC1VbmAfrXvPmWbTBZQOl992JyCy7pQS6XNYp1CFU6dwNsjkUdluqruP2jJpeT5UPLLjhokxTnQkoAyHZ+E6kfCYIMMNJy9512ejW2Q1QWgQlHj89iThGScC389GXCWVn5HgPD5mKtsNBRHK7FJDqEKFjR2NtFIiDSbdYh ECA== 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 Thu, Feb 20, 2025 at 04:29:51PM +0100, Vlastimil Babka wrote: > On 2/20/25 16:15, Dave Hansen wrote: > > On 2/19/25 21:20, Byungchul Park wrote: > >> I'm posting the latest version so that anyone can try luf mechanism if > >> wanted by any chance. However, I tagged RFC again because there are > >> still issues that should be resolved to merge to mainline: > > > > I don't see anything fundamentally different here from the last 11 > > versions. I think the entire approach is dangerous and basically makes > > things impossible to debug. It's not clear that some of the failure > > scenarios that I've brought up in the past have actually been fixed. > > Yes, and it's still an invasive change to the buddy allocator. Didn't want.. but admit. > IIRC at Plumbers the opinion in the audience was that there might be ways to > improve the batching on unmap to reduce the flushes without such an invasive > and potentially dangerous change? Has that been investigated? Sure. I tried like, by holding those pages not freed until either no one accesses the interesting pages or memory pressure is high. However, unfortunately it was super hard to fix performance degradation by the number of page reclaim increased due to the unfreed pages. > Also "Rebase on akpm/mm.git mm-unstable(5a7056135b) as of Nov 22, 2024." is > very outdated at this point? Sorry for that. I will rebase and share. Byungchul > > Thanks, > Vlastimil > > > What I've said here still stands: > > > >> https://lore.kernel.org/all/fab1dd64-c652-4160-93b4-7b483a8874da@intel.com/ > > > >> I think tglx would call all of this "tinkering". The approach to this > >> series is to "fix" narrow, specific cases that reviewers point out, make > >> it compile, then send it out again, hoping someone will apply it. > >> > >> So, for me, until the approach to this series changes: NAK, for x86. > >> Andrew, please don't take this series. Or, if you do, please drop the > >> patch enabling it on x86. > > > > I think I'd also like to stop being cc'd on this. If LUF is merged into > > mainline and proven to work on arm64 or riscv for a year, I'd be happy > > to take another look at enabling it on x86. I think that's just about > > the only thing that would make me reconsider. > >