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 09B66C02198 for ; Tue, 11 Feb 2025 01:53:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4384E28000A; Mon, 10 Feb 2025 20:53:23 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3C156280008; Mon, 10 Feb 2025 20:53:23 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2608B28000A; Mon, 10 Feb 2025 20:53:23 -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 05D47280008 for ; Mon, 10 Feb 2025 20:53:22 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 6FC35120A56 for ; Tue, 11 Feb 2025 01:53:22 +0000 (UTC) X-FDA: 83105991444.17.6961D59 Received: from invmail4.hynix.com (exvmail4.hynix.com [166.125.252.92]) by imf13.hostedemail.com (Postfix) with ESMTP id C931820008 for ; Tue, 11 Feb 2025 01:53:19 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf13.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=1739238800; 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=ElVSspQhnto8LauJhq5TqdWYrSHWP8/GH2ECV40J3WM=; b=gaKyP3zosk5RRVYclkO78OqcnhPIj6vcnGtANIgZeJknqo4VvuacTk6iiwy2M6ZxtO6asQ NAVnb6QA7SD1WZ1+yuQqDThUKO/HJ8V7AkT/bvAZyPSdQPAK5C6ePlmN87v1gg647uQBQy vhzlq56LHeHQI9w5dtyYq8nzEJ0Yh3E= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf13.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=1739238800; a=rsa-sha256; cv=none; b=DK7Z7ilb8fcTyUvBwpHr4WG/OzkwZcY8TrlVMv4wmhHKeKT1xiQewdIihAdMOfz2gkVt3A v4nOmuN2vp3FpxLpy+oF88UQsZuHcOBcZRE0n2rGcujs5MRUT7CwOJqYZ0zCberrbNsOWB HbssVn0its9Q+37OCOECwUjx9aYYYhY= X-AuditID: a67dfc5b-3e1ff7000001d7ae-94-67aaad8d83b4 Date: Tue, 11 Feb 2025 10:53:12 +0900 From: Byungchul Park To: Gregory Price Cc: "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: Re: [LSF/MM/BPF TOPIC] Restricting or migrating unmovable kernel allocations from slow tier Message-ID: <20250211015312.GA21555@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+NgFrrMLMWRmVeSWpSXmKPExsXC9ZZnoW7v2lXpBgtPSFlM7DGw+Hn3OLvF +VmnWCzurfnParHv9V5mi98/5rA5sHnsnHWX3aO77TK7x+YVWh6bPk1i95h8Yzmjx+dNcgFs UVw2Kak5mWWpRfp2CVwZLzZdYS14yVfRdXU2UwPjLe4uRk4OCQETiamTN7DA2Of+PASzWQRU JRZ/P8QEYrMJqEvcuPGTuYuRg0MEKN52xb2LkYuDWeANo8S/jRuZQOLCAmkSb3/4gZTzClhI 3F89gxWkRkjgKLPE7SOzWSASghInZz4Bs5kFtCRu/HsJ1sssIC2x/B8HSJhTwEzi5odrrCC2 qICyxIFtx5kgTtvDJtGyzx3ClpQ4uOIGywRGgVlIps5CMnUWwtQFjMyrGIUy88pyEzNzTPQy KvMyK/SS83M3MQKDelntn+gdjJ8uBB9iFOBgVOLhdXi1Ml2INbGsuDL3EKMEB7OSCK/JwhXp QrwpiZVVqUX58UWlOanFhxilOViUxHmNvpWnCAmkJ5akZqemFqQWwWSZODilGhgFa8L83rTe /esov/rA2i39B1bPZBT9aLy1VdL9952DnLWZ+03SVq545bG4oG3K03dXtq2sNM9xPpOaLH1M yCnPXWhNyMvLNXvW3p+0Ji3xvXhOsWrmm7siVfuXaMTrunUE7rOaNqnAlPvDYoXLlavUVr78 V5r1y2jjl7kCNseCp6eeX/58Z1aIEktxRqKhFnNRcSIAOUxD7GYCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCLMWRmVeSWpSXmKPExsXC5WfdrNu7dlW6wbRXghYTewwsft49zm7x +dlrZovDc0+yWpyfdYrF4t6a/6wW+17vZbb4/WMOmwOHx85Zd9k9utsus3tsXqHlsenTJHaP yTeWM3p8u+3hsfjFByaPz5vkAjiiuGxSUnMyy1KL9O0SuDJebLrCWvCSr6Lr6mymBsZb3F2M nBwSAiYS5/48ZAGxWQRUJRZ/P8QEYrMJqEvcuPGTuYuRg0MEKN52xb2LkYuDWeANo8S/jRuZ QOLCAmkSb3/4gZTzClhI3F89gxWkRkjgKLPE7SOzWSASghInZz4Bs5kFtCRu/HsJ1sssIC2x /B8HSJhTwEzi5odrrCC2qICyxIFtx5kmMPLOQtI9C0n3LITuBYzMqxhFMvPKchMzc0z1irMz KvMyK/SS83M3MQLDdlntn4k7GL9cdj/EKMDBqMTD6/FxZboQa2JZcWXuIUYJDmYlEV6ThSvS hXhTEiurUovy44tKc1KLDzFKc7AoifN6hacmCAmkJ5akZqemFqQWwWSZODilGhir9p5KSVAP kQkUmOFUc2SyDufLr5cV6vcdfpgnWyDKefWx1I3Wt+uy5+xISLv1OFSx8/4qr0NSP8IblCaL eB0//VX91o9/szczbjzjv6pa+mNNjkb6nukvDnR+FZgs+Ndv8pecs2yrGpf5/bRbOufJkytx dgJqyzWvcz5Z/DL4seorpX2XT16+pMRSnJFoqMVcVJwIAGFpnHFXAgAA X-CFilter-Loop: Reflected X-Rspam-User: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: C931820008 X-Stat-Signature: gjz5w1a4rnpyeqzyk3cch6hqwwb9rfeu X-HE-Tag: 1739238799-909302 X-HE-Meta: U2FsdGVkX1/YErA10RAeYu4An0J1jWzUMz30pDhprmpWUs1gGaJZr3vgXl5OtVWDMY/TXgUAnFE3/M+qkIgBAwu+IblharKN8wIfT3PBW842oc0UdmzyUVvZ3xd+xFl/a5OWTM4jzPasSnv2SiEwTkmCYk63x/51MeE7GsPUfIJ3dZjdOS+0G+cgfWzwPrFms6/DgZmNVUpnWe+57jcRJ6e3GGMoUAD53gi+rAH+3gHJrEllLOaVEytHH1Dx6zqcyM+aRCT+EsWlZcTVAdrM2PEa8zhanYaLwJAWqinkhSqZkW9g2bkUKaFJcwgUSUmHQg0uku8JIHtW4W3fP9Gfb22MbrVYR+rk78vc4G8Pmld2b1Hxvnj5Gcek3go5ZiRorY9KlFNgNMHyI8MBnjrpDGzWs+kDke/kVab+1ePbd4rXJmIAIDHBZBZtKXN7t0J4XgddsHKffFgRpv3REiWp6eT8u41iZwoLF53QuiwvYvZJmEIG2p1fAzjFDnodzp3AldB+72qxpUwxWKN7jhrqvws+SbLnybUldWJcL2srPEJowDi2Ju6FEFQPIunxZcbPogBubphe72qpYM4YRIhqXNrWSDQ6wlfmmFie6v76eL/5+q0fI2w/TbVksrV2lBmY9LRcY4cUymTy/LtRM5dn1QkLZJpKy1x0pFDTM2+YL95EQmklWbUDcAuDrtyMyUkMrs7bYgOJ3LKaJHFlm8mrxhmL4ZyGD5keolCNH6NK9l8a9MdfUpgr8BvCybhJajBaXkGHmGamlopTJCr3sMDFmXpPzvdWTE6dZfmQheVUYWp8zBkh7f18yV0FhnYMgd3CtAHe77PR28Aua4FkvXt7lRmPQoZW3rO4KSfwviATOmweh2cV+ugXcCObCF+DmOLT5rbhL9aT2Yo1eEJdg9Q/CL5XwtqszAu3c0ab/rSeiumVovD1R9fEpqeXbvJkSwUhRCW1plgHgsriwAzwvku vQBic5DQ VzWl6khFZnUMZcnE= 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 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. I have observed performance difference depending on page table's placement between DRAM and slow tier, that doesn't have to be CXL memory. We should place page table in DRAM as long as possible, but when not possible, we could do either recaiming DRAM for them or temporarily place them in slow tier and move to DRAM for better performance. But yes. If slow tier is *NEVER* allowed to be huge, then reclaiming DRAM would always work. This topic is valid only for the other case. > 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. > > I also think someone should actively ask whether `struct page` can be > hosted on remote memory without performance loss. I may look into this. JFYI, struct page, page table, and kernel stack were just example. Let's exclude ones that you don't think are feasible. However, I'd like to tell at least page table is an interesting kernel object in the topic. Byungchul > ~Gregory