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 9BED5C02192 for ; Fri, 7 Feb 2025 09:27:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2E3326B0092; Fri, 7 Feb 2025 04:27:41 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 29197280002; Fri, 7 Feb 2025 04:27:41 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 13476280001; Fri, 7 Feb 2025 04:27:41 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id E67556B0092 for ; Fri, 7 Feb 2025 04:27:40 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 8FB3C121810 for ; Fri, 7 Feb 2025 09:27:40 +0000 (UTC) X-FDA: 83092621080.25.3DC6068 Received: from mail-qk1-f180.google.com (mail-qk1-f180.google.com [209.85.222.180]) by imf21.hostedemail.com (Postfix) with ESMTP id B0BB41C0015 for ; Fri, 7 Feb 2025 09:27:38 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=gourry.net header.s=google header.b=dpX71mF8; dmarc=none; spf=pass (imf21.hostedemail.com: domain of gourry@gourry.net designates 209.85.222.180 as permitted sender) smtp.mailfrom=gourry@gourry.net ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738920458; a=rsa-sha256; cv=none; b=mCN/6Lo3ta+5DXFHo+ZNAvHRL2dnpa10Mgqz9eD8udjlY2F3+TB2cNKCYiN9HbVxuy7BL+ LMeddW8PHWVvrKscSDCwsvYJcSwNKcb3U4lXMP+gIHaBaUpFQU3r4g33hrVvxtAm9NHXs/ Mc1L4mm+TSlMiWiMdhwnpJMqhhOXGOE= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=gourry.net header.s=google header.b=dpX71mF8; dmarc=none; spf=pass (imf21.hostedemail.com: domain of gourry@gourry.net designates 209.85.222.180 as permitted sender) smtp.mailfrom=gourry@gourry.net ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738920458; 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=m/uMI1tK22C0XcXmMy8inP8Xd5AMUl+UVIdWHN2SnCA=; b=xuOTpdnmEHYZuUB8iYW35EsapVw9SFfQy8ZnO7QmBaOOE4VLN2XyKqzGM6RiUWptRrROoi 4jKvYCWf7Z777DW5trncC99CQv3HZNX41ke0RGuXNcVilo0TBMY+BGHvh48dCNjJujAdIG +UtsQBPzdu4xFStMk2bjs/lQqjZ6xwM= Received: by mail-qk1-f180.google.com with SMTP id af79cd13be357-7bcf32a6582so170134685a.1 for ; Fri, 07 Feb 2025 01:27:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1738920458; x=1739525258; 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=m/uMI1tK22C0XcXmMy8inP8Xd5AMUl+UVIdWHN2SnCA=; b=dpX71mF89z0OsyekYoWaIVe/FV99nyUHdyQUit6dkNCauG5ZULZG/NvtvbA++xhFab gvb3auYeqAzYXrvkSc9pwYfvZP59/XUpz8E3bBwCaBCs4X9OWHaH5iXDEchX4UkK3r2p qt13MvO3tm9sK+wByQcnMgtOXUYZpNMLFzdpRdb8dPavZXtb8k7b6+Xl8zwmGQ19pxe2 zh7JO/XrRqJeM0y1IDHbtZOp+DRRWif+jDCnqg/FWnzCThXjCNNxA3chHWnqclad3a8L 0v+QCnA6LgJX/qzELH2RmpwJTgORWV2m0RFaf2f7fd9636htCCXyIcrLLAyxusqpaz8+ 6gvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738920458; x=1739525258; 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=m/uMI1tK22C0XcXmMy8inP8Xd5AMUl+UVIdWHN2SnCA=; b=F8N6+GGxSIbHVtFzbAkPEPnxjLsd1d76PXY2Mt7bT/KWXy4Gc42VJEJcxFAflSI4RM dJ5pWyFHxyN/ta3+crXPDCUpXGHH2EPxzjw65crchT1WxZkoSkrX68D9V0i/j9IP1a1+ bz6ijMCFU0Z5oM9H0vgpdueHMEH7CnuQEH8EOATu7B8DUOJf5kT04j5w+tn37jPv3eQP O3yWkVKsyP3Jipe/ZoZ8hLh+t36w6nyyQN06sXYrOTlgvWZbp5cLORrNIHMlyk9nbegL c1QMoeS93ZssHkdLDTlFvCWik8Y9m428QsgNzYDgwhFLma0nI45+TsnKzYXj4SJSYgwB 3vOg== X-Forwarded-Encrypted: i=1; AJvYcCWsFvca25y+mddOeu6CzGZuS3jbHPnYFOP8iTs3WXZ9AwULOeUqJ/4vWILhL978eme4TO6ownkJTg==@kvack.org X-Gm-Message-State: AOJu0YyfAryFoRPcWuWLQbALIz27ZM7ualmjZzHXFC38b9Z8z4okpOtL ktu3GTImgm7nh6oZQ0EYl51DjJlKJ0yuzpN2bk8Ir1bWYTLCQgo9VZmbKzpWF+o= X-Gm-Gg: ASbGncsQ6yZd4y6O1BGF8pg3NwmfuJof3GE5ku+3VmUN9bghd1I2u1/mg8gv7KfVf7m XrFBCwh/NBiuKkKxzImtIHJbC4apYH7wRpV3DLI3BsiFXygAcyc+GE/lXXFqzKEWTh+6t7/sEha NCQszglaG8R53+0EaDIEXhIItrdZS3u1Pv7XpZ007JYeXeA6/olUvB8z8Mdc5M2K8TBrkEJ6Ji4 hsGOzhyfUglGjgEuerJ9UIaWOMGHvFiMabxh7ZCV9y5dHIC2Jw5JuKx4pASXqHEyCERhJ2nQYiY 81b5vKmXcAEqOwJcSRR6RyGzOUy3IEFu0FsbCBli1mhhCT8dyErxMI+BtYua/Nuv17KAngpRfQ= = X-Google-Smtp-Source: AGHT+IFJRp2jaR2qZ3cXfvTiU/3UzYoJIEOUnTN1p8TBNt5vL+bmEK6odcZXSkWnX6trVbJ5K/6Q4A== X-Received: by 2002:a05:620a:1990:b0:7b6:d65a:d6ea with SMTP id af79cd13be357-7c047c7891dmr406314785a.46.1738920457766; Fri, 07 Feb 2025 01:27:37 -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 af79cd13be357-7c041dedba2sm166192085a.16.2025.02.07.01.27.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 07 Feb 2025 01:27:37 -0800 (PST) Date: Fri, 7 Feb 2025 04:27:35 -0500 From: Gregory Price To: Byungchul Park Cc: Matthew Wilcox , Hyeonggon Yoo <42.hyeyoo@gmail.com>, lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org, linux-cxl@vger.kernel.org, Honggyu Kim , kernel_team@skhynix.com 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: B0BB41C0015 X-Rspamd-Server: rspam12 X-Stat-Signature: nxbg7ncoujwt3x3swwynadede9iwcy7i X-HE-Tag: 1738920458-598227 X-HE-Meta: U2FsdGVkX1+QC6rnrAxapDMMIOQeI4V5lfH8FvLbvjzTvvy0PZeeYyePIq2P9aJskHTg9VB94bDkmwWCCbRDJ96/g87k90bRQgN0e1PNyUjrmcotbHGrSpyK0luBLgAsuV1X5k3P4Ordi63xsWGlONXHaoLwXxGqng4Q2lAwgoK6wl0aFKu3DYPGeLSZNfs/ivD6amGu2zB7K/8CaY0TV4oqD0O/OZQDVjQOtMEmW/YP8qfAS4XneTDW1+OFIaxUZ1OQUAKUYOKjW3RIRhF5AdibcRYjowIzkiFIHK8x6HZ5KxXJvUaEhidkblEOdrrOKhGRs6uNnIGbrU2VPotCXD+uFQ6EUHPHL/k/M76xUyq1hu7Eo6gofaJkgjrnQX8CkRFh5Ww2imvucNFz/OjaYD8qcawuNiZgHh4PkSeDFliJH1vb52DeosAdTMViafaPtToyEdHKSElPl0mg//T5IGyfQoBkM86YDeCz15fDp2Q+pHkDzmdjfHXbcxh+0L92kosfSu3B6RHoavMhWqKNzSz1sgfp2BKcBvFJR/qYMtxvA3SJtI0sQKn736IScKzoaNLAr4/6RkcalyOJ16sHpWXiXB6V66TiqgJ7kbAlAgT0Yy7VIPMjp5BwAj2ASCE1Yo8K9GrofRfc6XFvEY+LkDw4bQ1sTV9z4xH5bPEvoBkd1LjUNz8QWU9lB/1J7s3UzEVyw7urLQcN+qb/GfQYAvsRTBN2zqJ42lILXKUIRHb+Hrj8qa7JrlFVlmbYw38PYqfR9+dlS/zbKu0MR1lEDXApC+XvS4FL3Um34c6CLnqcjTOYb3nqUEp5xRYL3GQg7FM2PRpXfwxggv73kIPI2d20ySMDY05waVVAzXANuRLUauXXWVsjGBw0Mf/R0WZpF6niCvno1LntsKP+0k1Ahr/t3EiDTvV2smPQN6HpYz5MGNMWKOoBTHoyB/5IxE5fFjzOjYxCOcFk/c8UV5i zncYhSIW WXF0eVOnneJIXNLNeFfYnGyzJX6zg8sWFD+bvgoKm/4YQOMko8E58LOrhFx2wzICL3RWBGtMHDg0ttyRs5PFKfYq4sWQoNL+tJb/z5vnFaR+MvPjvgqscWqyX30nXxCHCAw9OR5pI01Dv7jK3KOEybN1wv1JJEfpoBNAxseASdJN54kcCo36rMxDh58N8tJBouXq2ELZMyjRM4pVmof7onU7Kor6m9hr1/2ni+2AhrjhPZOfTsUktsE77or+y7a4YeM7v2N2CfO37B4N8uH49R2VFe4/JD4K3Ikqoobdv/43aEFBf84T1nzOitV7F5KaQccvj9dLEL8H72XNsieLL8fd+6xcc9aExp0LDA2UEWG6Hbf88AbK75vw0xiGfCes7y7iB+RUWo9KBaWPY/Zj2C5DstA== 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 07, 2025 at 03:57:45AM -0500, Gregory Price wrote: > On Fri, Feb 07, 2025 at 04:20:24PM +0900, Byungchul Park wrote: > > My thoughts here are that memory tiering is the wrong tool for the > problem you are trying to solve. > > Maybe there's a world in which we propose a ZONE_MEMDESC which is > exclusively used for `struct page` for a node. > > At least then you could design CXL capacities *around* that. > Dumb question time Is this maybe not an entirely horrible idea? Even at 16-byte page structs we use 4GB-per-1TB of capacity. Maybe a memory device providing additional capacity SHOULD be made (given the option?) to service its own struct pages - but maintain some control over hot-plug-ability? At least it could tear down all the ZONE_MOVABLE regions and finally release the MEMDESC region when finished. Seems too obvious to have not been proposed already. :shrug: ~Gregory