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 2DE75C0219B for ; Mon, 10 Feb 2025 03:19:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7FD616B007B; Sun, 9 Feb 2025 22:19:49 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 786586B0083; Sun, 9 Feb 2025 22:19:49 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6269C6B0085; Sun, 9 Feb 2025 22:19:49 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 44BB16B007B for ; Sun, 9 Feb 2025 22:19:49 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id DBB3E1A1F3D for ; Mon, 10 Feb 2025 03:19:48 +0000 (UTC) X-FDA: 83102580456.30.20BBEFA Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf02.hostedemail.com (Postfix) with ESMTP id 7671280003 for ; Mon, 10 Feb 2025 03:19:46 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=v5T0Xuwp; spf=none (imf02.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1739157587; 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=81QMFsBtwsH+yykszxn1E6ZFsqLFAbCVhQDafqF/ILE=; b=PF3WfuPwsqG7PF6FYmKfmIORoq9AIxtJorwf4h+P5kQ4QwMRdWpyFqIpgEyH+hBgwJtqlf 6NwlAl/X83fFNzpyhL8OAUIoG4oAQu/oJpkA07rZXvsHp6Qelanwlo1QOelOWJmBLyqnvS 0FQ+mGm2HtJNvFso+9OHQTCJtRNGUKY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739157587; a=rsa-sha256; cv=none; b=7To6NGa/5gZk/TMXxSX3wGs9DBNOQhAK5arAqOqjoTefFGAN7AQ5YetPz8JYGDAr4sKwbF ltbqHu+5LCK2F8HPk3QSvkcrBCmKw3FISaPImYD51tUPWHFUMBAT4vY5tjoVB8cQWENYEU S6E6BYeXhlkWVaUtphvJnOThvHe715A= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=v5T0Xuwp; spf=none (imf02.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=81QMFsBtwsH+yykszxn1E6ZFsqLFAbCVhQDafqF/ILE=; b=v5T0Xuwph3y1r52xw3m6Ze3Ke7 g5ZSU3IRYNnR8si6bdFsmFotEF77pq5AD4c9tG6FrU7tiAUZOQab9r/7F7MIb8bpQjqKp0WixXStq icsNrTGh/p//ZTKotlLxg8nahT676rmjRRG4KgeJrCMzsybl431tlFDo1rDv+m67fLHZ3spibe8Gq 1yRZtD7qSDst5kNuy1pIgn6ZuWZLKzUsuCS8hNhzWxz0XgYlTCgAKqqP9g24FF4U9j9fQr/OFifLP T9s2z4M5rv3i5Mydi1jWyvqeNisnfhKBP/v3qbIwG8wcjChk70jiNrPhZaYK+Ngsoa3WQtUf+kfbt +4utVckg==; Received: from willy by casper.infradead.org with local (Exim 4.98 #2 (Red Hat Linux)) id 1thKKg-0000000EbQO-0UxH; Mon, 10 Feb 2025 03:19:38 +0000 Date: Mon, 10 Feb 2025 03:19:37 +0000 From: Matthew Wilcox To: "Harry (Hyeonggon) Yoo" <42.hyeyoo@gmail.com> Cc: Gregory Price , Honggyu Kim , Byungchul Park , kernel_team@skhynix.com, 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: References: <20250207072024.GA48419@system.software.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Queue-Id: 7671280003 X-Rspamd-Server: rspam07 X-Stat-Signature: j4kuhr418o4awedhrsk1hq1kcgik4hcf X-HE-Tag: 1739157586-651259 X-HE-Meta: U2FsdGVkX1/Iw3g5rAHlUQ0D9R6Oi58sMtqEhL3fB+V7iT7UfUCBJnPldEsjEtsErctaJ75kGUBIzg8y9oAjcCFAQNiwOXC+VEgY6aYDS2kvBy6f/YIeNR+ICcOA7TuGvx7YJGU7RxB8D8LapsHpR16fViznGhhjhml3hGEAG1YKykLc0kfysakJQHoC2B1WKiar0kOdLjTzWH6oiCLMgYwY1N48Z0Nn98BDrXPWEu2r/Tm8Csgp6ODuqWGy6v4qBV6DhMptU3Zw3n/XdMvy1EYDE3bKhxoV7YFYsceeUVL3TrglGq5Z58oh6yq0iAgpBvc2nG69OSmbxFdyQlPY653WcUlLPJsm5eIP6XhOj6EziCPPO+nlMBDeNExbMJW4D48lyzka9Q95/fN68hOpV2gXuTiJIcadxC5M6Rn9PjvBeJpR1HXW57Pgu/g7MjXiwQxz48dqvpiA746669hXKrvhjyjEGY8Ot9F9CYybUNdB3u3M3BUH4R417mZEaE/x3jeyzc4Dc750fdt5wkxtFRYAiuKBkwBPsVFZBH6sZYfmknA4mzqbnbBur/3OQvwm0odAkr1V2owG3HQe0iUg8B7qFDWF8nRM5fbWJnZHNdo62L7Yn3YwNyDqG75hjLPwprpbYvjU1X/KrAcF3T2N9enn4ylHxebfQNq2jNtCu94s1/UA9fMVw+vP62h0SqTzKnkUNFI2Xj+98GWacabXN9MmfppMFYeZvzq3xiGD5/ZZu9+EWrBWBVnjAzYpbfJDsEU1bwRK0w4bjW30U2ccXotVB4IFwj3cNoEuCImK9TlxICWSwktrVjGV2ooibqbUYerGHPnqk8hJ1tMRlrv6YGGnp00F1BjLP8XE0eZdEVmP4VlZxo/lTgg7iCoH+AVXV7XwynHSs/FxhTBVGZ/4wivJhMYO2kLO5NqC9mFqVz7FTtYc5y53611g/EuFPctOGUYOr0rgAET2QwMSH4A u0P8OjRE T64BEBwlcDAsbh/n8U5mswKnXSjJlgCUiONhX+kmIyXhQRPDe7IQGycvCK1Tgv1lQvQLxp6RctSEh0zWF/FHCdB5Qp9NyYkR5mYXBoT1mYu/mjS7Lj7iAFWIwDIp1a39sVaEx6W/kOtZrPUjk37NFWo3CyOePxKSdy5UCe5aAPfktFWk+GX4fILKErEwpJl8BY6wNV11Rbnyliuh+XIVRfupYtN/2q2MFZe9qS8lbEidQBYsohtFZXTCV/WEIbp+Ri9QA+1yzDioLQUA6z4DH3hU8/Qf/JJQVx8ADMdMbQZ2i1VY= 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 11:33:47AM +0900, Harry (Hyeonggon) Yoo wrote: > Premise: Some ZONE_NORMAL capacity exists on CXL memory > due to its large capacity. I reject your premise. None of this is inevitable. Infiniband and ATM did not beocme dominant networking technologies. SOP did not dominate the storage industry. Itanium did not become the only CPU architcture that mattered. Similarly, CXL is a technically flawed protocol. Lots of money is being thrown at making it look inevitable, but fundamentally PCIe is a high-bandwidth protocol, not a low-latency protocol and it can't do the job. > > There's a reason most kernel allocations are not swappable. > > Because most kernel allocations cannot be swapped, with a few exceptions. > > However, there's non-LRU page migration functionality where kernel > allocations can be migrated. > > I don't understand why we shouldn't introduce more kernel movable memory > if that turns out to be beneficial? Because it's adding complexity for a stupid use-case. If you can make the case for making something migratable that's not currently without using CXL as a justification, then sure, let's do it. zsmalloc is migratable, and that makes a lot of sense. But there's a reason we only have three movable_operations structs defined in the kernel today. (also the whole non-LRU page migration needs overhauling to not use page->lru, but that's a separate matter. except it's not a separate matter because that's needed in order to shrink struct page.)