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 F30BEC021B1 for ; Thu, 20 Feb 2025 20:06:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7B9DB440205; Thu, 20 Feb 2025 15:06:21 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 769DE4401FE; Thu, 20 Feb 2025 15:06:21 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5E545440205; Thu, 20 Feb 2025 15:06:21 -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 3E8BF4401FE for ; Thu, 20 Feb 2025 15:06:21 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 08C0E1C9332 for ; Thu, 20 Feb 2025 20:06:21 +0000 (UTC) X-FDA: 83141404962.27.F1F1101 Received: from mail-qt1-f175.google.com (mail-qt1-f175.google.com [209.85.160.175]) by imf09.hostedemail.com (Postfix) with ESMTP id 50C3D140012 for ; Thu, 20 Feb 2025 20:06:18 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=gourry.net header.s=google header.b=U2bU4CLF; spf=pass (imf09.hostedemail.com: domain of gourry@gourry.net designates 209.85.160.175 as permitted sender) smtp.mailfrom=gourry@gourry.net; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740081978; 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=K1KlFOn7Hg/ku1RTZ3R0CMdwBj99t0GI1rv1OK6Mr2w=; b=djAISxnW8QO5ujTjOy4QF9EkLXFcuigf4kliWp9vDBSn/4/trTb4EsEWKZyB2Dl5hhJu+i HFG1C8NG65j3wQPHg2GV880UZU4dlRDZT6oV+Co6Zk8kvyqzwOKgErNu4LrudGw3WDamDF L7wf4pXDWgBiBiP3rV66skL00KNXj3A= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=gourry.net header.s=google header.b=U2bU4CLF; spf=pass (imf09.hostedemail.com: domain of gourry@gourry.net designates 209.85.160.175 as permitted sender) smtp.mailfrom=gourry@gourry.net; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740081978; a=rsa-sha256; cv=none; b=Wl8AzOqoopAZGtVOdHxSWDCzdnePuskkOcajv+Osv7duDholg1oy9A3pbXDXj9Ufvmrqy2 /qGNYffrnaIgsDD5mT7XLrfN+IrfeUa4T+VDn4yNPv8Ma10Op/SuB9lIqz6K/JALkqi6ch jmn8PkUSmhZiTTIdqgkpELO3hzNxKu0= Received: by mail-qt1-f175.google.com with SMTP id d75a77b69052e-4720cfc35e9so21500211cf.2 for ; Thu, 20 Feb 2025 12:06:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1740081977; x=1740686777; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=K1KlFOn7Hg/ku1RTZ3R0CMdwBj99t0GI1rv1OK6Mr2w=; b=U2bU4CLFUQa+DYKY8k2R9kczspp60+yrFjZWSci16mRBrgQEZK61CjSOd9MBbOu/gp 6GRh5dZkDNyHgdmyEBsPKGKhWsBKsEdYeLxHQyx4ACd9PeT+lP4tQFcsTdiZ40J5QWLP pmH/QXCVpazxp1ItAVkUpz+13cvEemjk0U2cXzQM34cjZM/o8mXJJhzinmcdZLnIwLNA hNH5OO7hNLbWj/2bY0wq2FSiLhFezbtu27bl0AQ7K9FQJkB0JupI1lgfiRTKMYziiGQ9 q4BKrrlRllmqWDQClOIEYfXDdCT8S6bv+IPrBNYn/DMFIQtGGWLWQhq/0CQvLZ0VEtWF xa/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740081977; x=1740686777; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=K1KlFOn7Hg/ku1RTZ3R0CMdwBj99t0GI1rv1OK6Mr2w=; b=IEA9BdkSOkiH7pYrRFxSot/7qo5PM+fGL/KdVSuK1bhZ72/UcbjliMtwCi7Lf6EzFV GuctlkzKZa9tdTjcRmuF6UzEibiyARUkLuOKy9PfHeQgOWw1VhplKHyEdOhT2u5FvaLg tJ2wCjNkFFND327xL23BYqFPWAYgc9MYcoOcc1bz0mBjBd0SVDZQUwlX9VD5rIdSnJt9 L7a2YtKc5iDe4CCZTIvSvUUHLKN+67b/l6ai+54pSDH6XODu58QuPj+DLR0cg/qNwFHj gq+ocSsHOkkgZNON4uenOVQomgoY+ExPxG7l7btdzwOu/bORBAZ5+YVFLBrG2GlxF46M X5dQ== X-Forwarded-Encrypted: i=1; AJvYcCVPaA/FTo6yrxHL6FFJxoB/vA9eoW94jaCKa3fyePKorrq09fH73whRexLC261jpLHS1Ia1zoazpg==@kvack.org X-Gm-Message-State: AOJu0YzKFGvSTyr+TEdcFcdyfVPNaDTwxAHmDZdY1b1gP7mPPgyFV02N nIsL0w0sUdZnMyrP9JT/GUKHN3dvgISoaO9rvJ9aHOIG/CYuJ/Agu+qU8J/EFMk= X-Gm-Gg: ASbGnctuCaYIrG4TJ4oPNAyZpWMGxSLKwY42bO060R3L2TMH0zZkdf+rpZw6IO2qXj7 miX7s00KlzBWPTEquCT+wnbmC6wdSesOoXPbyrxKxjDnrNpa2kTbRiy85UrRozfFvKHkJyaK5Te xHv1Zm8FbV8LfoevUUMNhVgcK0TxHnJFX8fn5fyNCxY+Z0vtq5yEuWP2iWcQGNkWlB2OccDD6iM ibDZsg0tbVHp6yiGZYLeTRwIqHwKe1MdIahCQchzczpBOVG6rW7rJKgzDozllFRRrFgIkzzSuD0 J0jrL1xSLCfufmrWagreoEIgZpGGDrBBUVJ75aAXf6HHLDsi3Wcbw4Vk1KX9UF1+YrlzhQCzgg= = X-Google-Smtp-Source: AGHT+IFqBXc3noHLl5J5ssCf0WWyGmo3wgivenGX96bW8nMSdpZU57GvoBw1O5ge2vFl9td66zPrCg== X-Received: by 2002:a05:622a:13c7:b0:471:f3f2:62eb with SMTP id d75a77b69052e-472228ce17amr8517751cf.19.1740081977267; Thu, 20 Feb 2025 12:06:17 -0800 (PST) Received: from gourry-fedora-PF4VCD3F (pool-173-79-56-208.washdc.fios.verizon.net. [173.79.56.208]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-471ead6bdeesm51910061cf.32.2025.02.20.12.06.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 20 Feb 2025 12:06:16 -0800 (PST) Date: Thu, 20 Feb 2025 15:06:15 -0500 From: Gregory Price To: David Hildenbrand Cc: Yang Shi , lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org, linux-cxl@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: CXL Boot to Bash - Section 3: Memory (block) Hotplug Message-ID: References: <1b4c6442-a2b0-4290-8b89-c7b82a66d358@redhat.com> <4ae838ee-b079-408e-8799-e9530ca50417@redhat.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: 50C3D140012 X-Stat-Signature: jztur4ug9bwyay64g6t7g4w81ysucb45 X-Rspamd-Server: rspam03 X-HE-Tag: 1740081978-827644 X-HE-Meta: U2FsdGVkX19DTCBgYn5STbELPpvspNbbEwc0dTwvCZUXHbECkvBnZf0+hSvP1FVsLT6ABHfxFchNRagFEb0FZQgUXy/0Y8Rhs/d3yyBJ4g+vHcsZC00kidsXyd/DT5HKkk0f3dcSRg2s0tisTCpGxLReAzW1qToXweo2rMwsgHUDCElCLYPnhptx/VrS/uU9t36zNZnPWZaGecazxmJGH5Mk/nbVTK5z1FU7Ta+/XpT5gd6ZXrQOSmRA0ODu1G2quJCvYK423PZEOUxg2a1lHpPiDY5ruTwef87W/3RJBd/54aN3RY93BMxmdsIhKokdBkpNL2e4HOex9wZw6SWqGEyqu2FqY9s94kMFhDFNYX+BIw7/A0k+tZ0wOLnCZJINR9/X2ut658cBfsVscG24UZEtUXOMhzHGtQ0GS94tK0650L7sDkhSkLseLYQhQhg4C9sEKb2rx23f10aREN/jYT9hZQAq1AL0N2opGeLQOjnuwBNCsdolGSv8VWlDhfmWgmMjIOEBCoi3l7L8LOgIhi5jUKawrVyO2slKqyBsrzV2egUoCmWiO0DJig92p+0lvqLb7F8LqSXUwFEGWW9XUCbWLTlVuc6DtkiamnnlZZPu9qypraDpH+XJvpBz6NsWk00fq2H6cdA0u8Cy2GVZg8KT4F8FaraduBQ6uo4+wwf5Rz3jBROVdyVpUweMXkPxbeorFoUnKWEWMvxFQSn4JWdMQwZf8Rq6G09tL68IEWkR886eiDadth1xcWDQOyukYDBQ/8/1mAZkxoFzmrqADoaYanjnIRy3NBWRZ5gulOlSMOX8P92Q7PgGN8XLmP2zTK6Sj72eHL53NmYfOhJhMn2SDBjIWFurdEgg6AePtZQoKj2OzuBg3/RxbWBhSUm/iVSiupbSFbO5vuzq+R+Atnnp8rBsUYRHcCb4yy5dv38qYGgUIq29dCNsqOXaFlVIJ2UoXEJU0ZuFL6yZSSV 48upLvwv M+QsS+Hf6lKiknAaaG0dqUGn7exLNsQ/Abmw/pxbu1C8y8cHwGIhDHm7YUT2jZLiZG1BvLR3zQvgoVwSxFVvVY9SN6wLx1gGDlM2AjEOYwns62dCNsdiG3EvWGdvkT8koXPVQS1LmW5iuVNRfTCa1oi2EtaP5CNaVY4qFh7zqVCgMgeBd5yZA5EgD1EtiRjHxIC7y0odiQRujt0/DcxBP5q7FsgwPiZ5Yzl3eowYR3TBvLRomxaGgeRNJE1a8opOXER8iXpWbs/PPpz+gfTdHUkSRvmm2nOtsoaOfxXu52MYflQlk6Y53Brl6r64n/hoIJQ+qwCY9M48/OkQ= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000279, 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 08:44:36PM +0100, David Hildenbrand wrote: > On 20.02.25 20:35, Gregory Price wrote: > > There were some discussions around variable-sized memory blocks. But we > cannot rip out the old stuff, because it breaks API and thereby Linux user > space. There would have to be a world switch (e.g., kernel cmdline, config > option) > > ... and some corner cases are rather nasty (e.g., hotunplugging boot memory, > where we only learn from ACPI which regions actually belong to a single > DIMM; dlpar hotunplugging individual memory blocks of boot memory IIRC). > Probably we just end back up between a rock and a hard place then. Let me finish this documentation series and cleaning up corrections and I'll come back around on this and figure out if it's feasible. If variable sized memory blocks in infeasible, then the only solution to misaligned memory regions seems to be to wag a finger at hardware vendors as Dan suggests. Thinking about my current acpi/block size extension, it does seem bad that the user can't choose to force a larger block sizes without a boot parameter - but i hesitate to add *yet another* switch on top of that. The problem is complicated enough. ~Gregory