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 DF229C021B2 for ; Tue, 25 Feb 2025 04:55:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 70DA36B0085; Mon, 24 Feb 2025 23:55:06 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6BE6F280001; Mon, 24 Feb 2025 23:55:06 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 585716B0089; Mon, 24 Feb 2025 23:55:06 -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 3BEFF6B0085 for ; Mon, 24 Feb 2025 23:55:06 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id AC5FC160929 for ; Tue, 25 Feb 2025 04:55:05 +0000 (UTC) X-FDA: 83157252570.24.11E0CEF Received: from invmail4.hynix.com (exvmail4.skhynix.com [166.125.252.92]) by imf13.hostedemail.com (Postfix) with ESMTP id 2F80F2000B for ; Tue, 25 Feb 2025 04:55:02 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=none; spf=pass (imf13.hostedemail.com: domain of byungchul@sk.com designates 166.125.252.92 as permitted sender) smtp.mailfrom=byungchul@sk.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740459303; a=rsa-sha256; cv=none; b=tKcg3HN3y99wG9YkexWR7B32Muhp8AiBL634ti/4KSzrjBDh5wXBqF4iM3IBMjtgTXqu5d PgfywkvMgmlpLj4pDIsk/WYJhZdTuetAj07pfGXGlY9CpkwRThr0NPYKEVTrlCztH+gT6B 4TeOgF/oRapBX+u6rc33uatFjD9vyvI= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=none; spf=pass (imf13.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=1740459303; 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=JBo8MLP5cOv7lzqpqvNM8LosUWesxUPIqKF73u83F9o=; b=nSPGv5ehnEtZDIIU1FNWHVQCzllzLPJKX18Jp6y8lifIhhLqVCG1gHuXs92HzSo06uBT1b V0OeNNDKrAkWMV/u75XVrz9FUpHriHBtBdE1fjeBV0NBWvrjJ6rPGWOFyNz9yWJKMySNLL OQG37V/S9D5sbSjTIlYwzkvC2gSHla8= X-AuditID: a67dfc5b-3c9ff7000001d7ae-e0-67bd4d22ecea Date: Tue, 25 Feb 2025 13:54:53 +0900 From: Byungchul Park To: Harry Yoo Cc: Gregory Price , "Harry (Hyeonggon) Yoo" <42.hyeyoo@gmail.com>, Honggyu Kim , kernel_team@skhynix.com, Matthew Wilcox , lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org, linux-cxl@vger.kernel.org Subject: [LSF/MM/BPF TOPIC] Gathering ideas to reduce ZONE_NORMAL cost Message-ID: <20250225045453.GA38036@system.software.com> References: <20250207072024.GA48419@system.software.com> <20250210071741.GB39454@system.software.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+NgFrrHLMWRmVeSWpSXmKPExsXC9ZZnka6S7950gw0PNSwm9hhY/Lx7nN3i /rJnLBbnZ51isbi35j+rxb7Xe5ktfv+Yw+bA7rFz1l12j+62y+wem1doeWz6NIndY/KN5Ywe H5/eYvH4vEkugD2KyyYlNSezLLVI3y6BK2PxxilsBb0SFRf+bGdrYHwv1MXIySEhYCIx/ch3 dhh78+rlzCA2i4CqxN4Dm5lAbDYBdYkbN36CxUUEVCTeHjvE1sXIxcEsMJFJYtGy10AJDg5h ATeJU1MzQGp4BSwkJv9cC1YjJLCVWeLY7zVMEAlBiZMzn7CA2MwCWhI3/r1kAullFpCWWP6P A8TkBNp7vT8CpEJUQFniwLbjTCBjJAROsEnMfd3PCnGnpMTBFTdYJjAKzEIydRaSqbMQpi5g ZF7FKJSZV5abmJljopdRmZdZoZecn7uJERjqy2r/RO9g/HQh+BCjAAejEg+vQ/yedCHWxLLi ytxDjBIczEoivJyZQCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8Rt/KU4QE0hNLUrNTUwtSi2Cy TBycUg2MHkInY0Q7FkTEbL0Vw/fDSGNCTHHfz6ULhCNepJt8nXWxTXvdqzf7tzxZJtn5V/cN Y4L15m0NvKd2/Q9l6D56WjAlaob8rv27T0cbbl5SZFR8IFvKTI3nvudtzxYTppOVnUkNr7/u WrFgKVftlD0fjrKf7JcXYsq59EScZaVmZ9iEhUfu9Z1VU2Ipzkg01GIuKk4EAFU3RwxxAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHLMWRmVeSWpSXmKPExsXC5WfdrKvkuzfdoPeIvMXEHgOLn3ePs1vc X/aMxeLzs9fMFofnnmS1OD/rFIvFvTX/WS32vd7LbPH7xxw2B06PnbPusnt0t11m99i8Qstj 06dJ7B6Tbyxn9Pj49BaLx7fbHh6LX3xg8vi8SS6AM4rLJiU1J7MstUjfLoErY/HGKWwFvRIV F/5sZ2tgfC/UxcjJISFgIrF59XJmEJtFQFVi74HNTCA2m4C6xI0bP8HiIgIqEm+PHWLrYuTi YBaYyCSxaNlroAQHh7CAm8SpqRkgNbwCFhKTf64FqxES2Moscez3GiaIhKDEyZlPWEBsZgEt iRv/XjKB9DILSEss/8cBYnIC7b3eHwFSISqgLHFg23GmCYy8s5A0z0LSPAuheQEj8ypGkcy8 stzEzBxTveLsjMq8zAq95PzcTYzAUF5W+2fiDsYvl90PMQpwMCrx8DrE70kXYk0sK67MPcQo wcGsJMLLmQkU4k1JrKxKLcqPLyrNSS0+xCjNwaIkzusVnpogJJCeWJKanZpakFoEk2Xi4JRq YAybdORS2c/X1u5uawtXHjl6Yc+hufNYrZZdnqCiUzhxtvTr61Pn7/M5c6qxaGKU1MalD4N2 LryzTPDffokazg2TtWtb46PX/q2cezlAvO+I+Ne9PwMz9qc3SVxkXpPilSGrweh7yz5/7jpl vhJPSd4vK17tsppgOo3RJo/5fdsW6wC5NpYLv+YpsRRnJBpqMRcVJwIAMyz+jGECAAA= X-CFilter-Loop: Reflected X-Stat-Signature: dqq1d9g1uccq17xj8fecjgrbqzcoqyp9 X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 2F80F2000B X-Rspam-User: X-HE-Tag: 1740459302-263605 X-HE-Meta: U2FsdGVkX192H7xrg5KtVsG8relSDBrBMRUuCLMoo23haNUR5MwKT8kCknPNDALqqJQZr8gRydGdsugOmvn6Ip7yV/7iqC+rsetfDEODU7GPalhdngiZ1mG9bxqV+K8RGpkRP8KB9lq4V5Qmn18Pk4QJF5ZFnew9Qe+sVvVhetICA4H/RPDgqArCz3O65bSLPFaPRYBHfHhddYD4i4xs4oTHrKlUtak35aRxHqQQkgc0WKWCF7CL4wW3OE2+//h9GikXq350WtSYmGU+u3zD3ZoQLCTxwBHvNeJpt5oI4+21vrE0PFvZAPnp1AcrSRR8K8hHwbtFa/O08a0PvkLZRHSWfHqyYjNswwRwmIKip2D/pl0waS5jkmqz9FparEdGrJ+PgzOzP08vfK6dw4MGu5yXBJMceq9O+mtN9vXliPppDZYXkZR1go1gQNsX/1Z6AM9q833eojoW9JCJTaqbx1PR24TTXNadpCV0sa25aKIFhYaJP1ctkDXJViZebjBsOrpFdJKnVjo9uDQpE47uRTZ0aTswpzCxhug7WHoq9fPJfB4RIiKmvQR5CtnE4LC3dZIlLpDEaSRHytKOrA4aq5IV2ee+kmIkfI4EJ2qgYGCUv2WNQKWMYp3I32C+XMhBAnauKceHEkuD9bA1JCYkgByS8Gf3m1ThXq/ZWxFtHHV59vKSkOMi+N18LwuTxHOMFRCWadC4Y84Q3R9gXDlXN3nb9QpXNls5Q1v/bc8IyztQyzInBDGtJ/HKq+3MK3gIJ0+kBusAbVqACavt4vugRWcGRPuQjZQAG4ZQsD383B2RoY1nejtQ+I5QfreV0o+Af51h1hOD57nlgzzIDPuT9aqJ3/MvayXxkXn3x7Ei/YEBS1SleLJvYRNj5W+AXfJZfE0OoQymLMv4uJvVst/YWvUaFagslS107t5DIg98iUoPjwP8Qre2qfyRAEsdLizyC+icxfv4s9K72Ugpgnt 0LsCxQnR 7fIGMKaDPOjeATWUVHz9E3BcLbCyXHdLdSAL+nK1wr2veDeB+DF41r8L1fe673CWcsyKJYNLeNsECcyIO9Xx4sGW4FLMbUlGo0x1dWEWH6Yu5hE4oa4qlIhTMe1myv3VYv8HzI+QG95mLm85majtgZT6QZOuYVFRcs1mTSfPIFXePJ5k= 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, Feb 21, 2025 at 10:52:09AM +0900, Harry Yoo wrote: > On Mon, Feb 10, 2025 at 10:47:58AM -0500, Gregory Price wrote: > > On Mon, Feb 10, 2025 at 04:17:41PM +0900, Byungchul Park wrote: > > > On Mon, Feb 10, 2025 at 01:00:02AM -0500, Gregory Price wrote: > > > > > > > > You can probably actually (maybe?) collect data on this today - but > > > > you still have to contend with #2 and #3. > > > > > > Ah. You seem to mean those works should be serialized. Right? If it > > > should be for some reason, then it could be sensible. > > > > > > > I'm suggesting that there isn't a strong reason (yet) to consider such a > > complicated change. As Willy has said, it's a fairly fundamental change > > for a single-reason (CXL), which does not bode well for its acceptance. > > > > Honestly trying to save you some frustration. It would behoove you to > > find stronger reasons (w/ data) or consider different solutions. Right > > now there are stronger, simplers solutions to the ZONE_NORMAL capacity > > issue (struct page resize, huge pages) for possible capacities. > > Hi, apologies for my late reply. I recently went through a career change. > > I truly appreciate your and Matthew's feedback and thank you for saving us > from frustration. I agree that we need a stronger motivation > and data to introduce such a fundamental change. And I also agree that > it's more appropriate to pursue what can be useful for genral MM users > rather than introducing MM changes just for CXL. > > With that context, Byungchul and I agree it's a better direction: > Reducing ZONE_NORMAL cost for ZONE_MOVABLE capacity, which is beneficial > for ZONE_MOVABLE users in general, regardless of whether the user is using > CXL memory or not. > > Let me organize a few steps to pursue: > > - Willy's shrinking struct page project > - https://fosdem.org/2025/schedule/event/fosdem-2025-4860-shrinking-memmap/ > - https://kernelnewbies.org/MatthewWilcox/Memdescs/Path > - Side note: Byungchul started working on separating the descriptor > of the pagepool bump allocator > > - Slab Movable Objects: This makes sense even without CXL > as migrating unreclaimable slab will improve compaction success rate. > It also has been tried in the past by others, but was suspended > due to lack of data. > > I'm looking for workloads that allocate a decent amount of unreclaimable > slab AND performs migration frequently - for evaluation. > > I might be missing some projects that could be useful, > please feel free to add if there is any. So.. Let's change the LSF/MM/BPF topic slightly. Byungchul > And for page table migration, while it might be doable even without CXL, > we need strong data that suggests that it's actually makes MM better > to pursue this. > > > I also think someone should actively ask whether `struct page` can be > > hosted on remote memory without performance loss. I may look into this. > > Did you have a chance to look at this? > > -- > Cheers, > Harry