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 C717DC0218A for ; Sat, 1 Feb 2025 15:13:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 122BD6B007B; Sat, 1 Feb 2025 10:13:41 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0D1E66B0082; Sat, 1 Feb 2025 10:13:41 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EDB1D6B0083; Sat, 1 Feb 2025 10:13:40 -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 D0FCF6B007B for ; Sat, 1 Feb 2025 10:13:40 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 5DBD3A18C2 for ; Sat, 1 Feb 2025 15:13:40 +0000 (UTC) X-FDA: 83071720200.28.C6B60FF Received: from mail-lf1-f52.google.com (mail-lf1-f52.google.com [209.85.167.52]) by imf04.hostedemail.com (Postfix) with ESMTP id 5B47D40002 for ; Sat, 1 Feb 2025 15:13:38 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=JXpn7neC; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf04.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.167.52 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738422818; a=rsa-sha256; cv=none; b=U3dCEJf/5CkomW3bN6KV4LBuCn7bHyPAZhzF5xa5B5dEEIVcKmW9b0RQ3I7cFhY60YoOM6 QudY5bIXAGb/+GnEe75BncP//cbNO8sx7L2rwpQdT6LGz5FJ+Up5M+fcaUTz1zzksdEG0g mDw+yiexjOYXXf1RmZNzicAF0csnazk= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=JXpn7neC; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf04.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.167.52 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738422818; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=gkEBogS3njtSSMnywk8aHqS941/Oe9cAxXVD76zALzI=; b=Tize/z4ExijgVEyl5UYkevdYY7BsUTj6nzaZkRE3vlmrrJKPExZe1b3DlELt5mpV2YUCeZ Ru2G1tCYgWzeWdQXKZNeK0mDud02R8c1T+8pw9i6W1g2H9kvdlBjRRA5upHemfncbvAss9 /hBjJiu9TpaoezxWLRoglhEnAbMZWQY= Received: by mail-lf1-f52.google.com with SMTP id 2adb3069b0e04-54021daa6cbso3157717e87.0 for ; Sat, 01 Feb 2025 07:13:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1738422816; x=1739027616; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=gkEBogS3njtSSMnywk8aHqS941/Oe9cAxXVD76zALzI=; b=JXpn7neChllwC3RBR6HLOfLNaJJRqCGcLzal2sBay3ezAwSW+HZUOBiKQCx5eI1ph/ 8Nk529A/cESinlrW9Tl0MBt46staXC3mydPXi3x4+eB5NITYug3RnsV/rJqoPvjQuP1Q EjRol/IaVrylhMD8xouc9wjcUBd2LBF9NMvzHXPGMnTc9auEG15/9GBGqkR6YQmxawfu O+lqgVnYKb5ReoUXM7j/3owVRG+t1IwsvdT2U70J5IFnuYgfbGEQmPBivMJnEZZOATIb LiZeDJq/kSaMQPKM8+RxnP6fM9Hzq48FzP44C7qsGq48Z37GAx+1YfaOX0UAnEzvAsJP MpWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738422816; x=1739027616; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=gkEBogS3njtSSMnywk8aHqS941/Oe9cAxXVD76zALzI=; b=ezZDbi/eJCn6NTtPV72m1csEZIuD1xNtKnadTBiLu1dK6qqAwb6DKdFf2qsa8uV1GH NVUakz3xRfqIUdwDEeDE1xaznStub/Y8l128Soqn4sYKW4a6g75pYHG39xB49y+uZ4WF wkHVQisgjm6IXqHCiAzT/j2oGGIlRkMWdDcweMHq37vNxmJwu1UZPX1v/iHbh1kzt2dF GKNz4GMd49A6IlMHM5kGMP6gDmFgfVltly7wsG1FUczXjwL5wEihwKhJxkcBwdBd6F1w 4HOreeCB+SCQbQWUOAgC1YU2qRy4kMCDenBIG/QRnZBBUN4HU9k4X4o2jpbG4zxCFMVu OT6g== X-Forwarded-Encrypted: i=1; AJvYcCVFlJ6HWRFlvmivyxIYO8Jy5MCMcQfedd8vq2qZe26bfvgsx2Ra4J51sJOKgAaWZ7FoRBbJLPvK3Q==@kvack.org X-Gm-Message-State: AOJu0Yzb/+h2LbJZg542GILWTJzuiBLAOTRWVdDogulsu4CCJMKGc3SL hQxmv1qW+ngJKNkc6/UTbgh+rpNke1mHqtz4ChIxeEoDxLJyb7wAL8uAW1FUvT12Uui0YV71E4Z yFfZkI1uwyMptSG3jiDlwhnb+D7I= X-Gm-Gg: ASbGncvgeS5Un3ftFn1StiE24YnSV9U2c+8f7CRL+LrZMXT2AuSDvP2A5dTpA2eOopt WCdP1yOJzb9bX5+nHNsA4U73RkMByhRJuxjo1DN+mtT9j99gL5AUrR0AgwfnjN5wKqeKS270= X-Google-Smtp-Source: AGHT+IFfMfRi/0COUKqps4xd0EcyGK5Kl+QVlFhrzOrq4+TfuZU0DPTzGpcqh5smpGzQ4g+0aW7aWCktvFQadk+sYt8= X-Received: by 2002:a05:6512:234c:b0:542:1c1e:ea7f with SMTP id 2adb3069b0e04-543e4be02b2mr4279832e87.9.1738422816115; Sat, 01 Feb 2025 07:13:36 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Hyeonggon Yoo <42.hyeyoo@gmail.com> Date: Sun, 2 Feb 2025 00:13:23 +0900 X-Gm-Features: AWEUYZlN48gcqVlRk5gKbITpV0iJCmnAxWMamnjQC7e9Mr2TA7FjeYRSh9-U1E4 Message-ID: Subject: Re: [LSF/MM/BPF TOPIC] Restricting or migrating unmovable kernel allocations from slow tier To: Matthew Wilcox Cc: lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org, linux-cxl@vger.kernel.org, Byungchul Park , Honggyu Kim Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 5B47D40002 X-Stat-Signature: wim54tj9aipm3i7pec7bmn5zbqy1q6qq X-Rspam-User: X-HE-Tag: 1738422818-331624 X-HE-Meta: U2FsdGVkX19Co4NIyQj26TulKPfpyp3M0o2I7eCA/63DGWksavRbxGc3eXZ9IQJnOXDociXeCtEI9sACsJ23OzqmdF6JU2BhOBgJ1zIhZHYBCoNK6aKtT2PU+dupRFRAV3a+GxkUsY1g67RaYmIAZA2UTf24FHNClwC/qghoXD8+XZrMknJu3UBqAUpYq6zJZq323VtlTuFkpNckuDdfmFIVcvpf9xaa1iJItpWd2/HzcZTbnjgmInFOMgB3vurmzeoBzvyhf1UHxbZQLf1t5aINkfJBbFjxEAWPpg2L6gucioUcBaKZ/xYnVtyLptoUnTFmZyNyC1Y1cGmCkt7qqAS5hm8c7Pnzx4CwZCk5yas38VWoBUPstDlflj8+ZTQquKvW6bu6yFBoPFeWRE6HUUIn2jAl0KYPbSlVRED6xQFzls/Kgdev95fE1b2Pn0ACPB81NNkDPCEinoChHXNzPrUkj2xx6agz1ENznFhpVj8NugiJUBj00FjHJGQEkETpu1jSUvmT0/81FIHmUlQa9vi7brAPJZN+QkT5E0ZQT+BnqTRFD0Byiq8edgxWfFu+LmOnXVfBM8MiDU3578fbzM0uzd+a1a79zBhtMo8/m+BlmC5eLR1zY2d82+puLBsDjp1PmmR5who9LQ0C9PTU3U3ldeCsX6SzXV1jCVTUWlYHQPvt/qnnz9JtgWO2/28h8uMOyZBsmQVMR58/VUAuxOdWGSosck3bk6V7n4KA2dQSISnlG7mrhOmTjm0uZVnjz+ioAF16o6xipGLj5cRKD8mKMyE/9INH+JT6UijrtqVxIawRGNXMXvDOUqiZgFxvywHb3haJa1DMX1nBUQoHBD/Z48sYTaqW1z4+QOIwRJtFsDeTykX2FIjihX6JvVSgQilNir9fKd8h9/It/q0ILiQPbaVJ8/O0J/7BUHpfdFkr9jwnn84thzpM0L/0cRDQ7x6BMQGWCjSvCvs8eF6 6cDKSnSF Um9nuLHDNqofeqdnhrd5IvDOKjgFdgT8Za7WG1JiWVgrXIqIqP4rpV7xqH3ktpTJX2LA3c525Fc2UaRUaY8VzSHYBSHGZnKFg+rRI1j8hKJl3wwplykKsw1ecSrTWgl5QaOyjOQ7cDPi8xHEj1GnETt+X7GqvurmuA7O5y8UTjNa8rkStJgfd7vQWj55tptjvz++Rft8gYJaIf2UOv3V8f6pCJKVMa/F/Zb7oVY3wJsHIu2tlpnHer/UJRB1Ri39spgrTAsUK3m/rHbQTtMxYYq9TDecKI/DhKp3eLOADUuZ8kP4Y2MOIQBdGdFeWHaUgVlS25dxFWBa6wdtRHWOvvnhIzS85vcQ8D7gg2ze3zL8rnp+qAcrR4TWz08okO8NPKR65t8qzlkL88BdF3Sartbe8/g== X-Bogosity: Ham, tests=bogofilter, spamicity=0.003914, 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 Sat, Feb 1, 2025 at 11:04=E2=80=AFPM Matthew Wilcox wrote: > > On Sat, Feb 01, 2025 at 10:29:23PM +0900, Hyeonggon Yoo wrote: > > The Linux kernel supports hot-plugging CXL memory via dax/kmem function= ality. > > The hot-plugged memory allows either unmovable kernel allocations > > (ZONE_NORMAL), or restricts them to movable allocations (ZONE_MOVABLE) > > depending on the hot-plug policy. > > This all seems like a grand waste of time. Don't do that. Don't allow > kernel allocations from CXL at all. Don't build systems that have > vast quantities of CXL memory (or if you do, expose it as really fast > swap, not as memory). > > All of the CXL topics I see this year are "It really hurts performance > when ..." and my reaction is "Yes, I told you it would hurt and you did > it anyway". Just stop doing it. CXL is this decade's Infiniband / ATM > / (name your favourite misguided dead technology here). Hi, Matthew. Thank you for sharing your opinion. I don't want to introduce too much complexity to MM due to CXL madness eith= er, but I think at least we need to guide users who buy CXL hardware to avoid doing stupid things. My initial subject was "Clearly documenting the use cases of memhp_default_state=3Donline{,_kernel}" because at first glance, it was deemed usable for allowing kernel allocations from CXL, which turned out to be not after some evaluation. So there are a few questions from my side: - Why do we support onlining CXL memory as ZONE_NORMAL then? - Can we remove the feature completely? - Or shouldn't we at least warn users adequately about it in the documentat= ion? I genuinely don't want to see users misusing it either. Best, Hyeonggon > You can't stop other people from doing foolish things, but you don't have= to join in. > And we don't have to take stupid patches.