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 D36A0D6A221 for ; Thu, 14 Nov 2024 20:29:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2108E6B0085; Thu, 14 Nov 2024 15:29:23 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1C09D6B0089; Thu, 14 Nov 2024 15:29:23 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0AF916B008C; Thu, 14 Nov 2024 15:29:23 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id E442B6B0085 for ; Thu, 14 Nov 2024 15:29:22 -0500 (EST) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id A928AA1485 for ; Thu, 14 Nov 2024 20:29:22 +0000 (UTC) X-FDA: 82785839682.16.BC230D7 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf29.hostedemail.com (Postfix) with ESMTP id 040D1120002 for ; Thu, 14 Nov 2024 20:28:19 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=VIwLOOWN; spf=none (imf29.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=1731616016; 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=Z0aBHXXkP5UPuougQYO6Mqdo8Z0I9yuUFBmW3kdCRQI=; b=jURhogEKSif+F4vP/E5CtIro9xbbLWy6S/2HZZ71kmAqlJmdmIJlOYWHvNIrBrW7buO9c6 qommvYJMfKezuGR1SOP96vO7Dr/5gFGGBuP7i+vbgOHJCt9l+SI0WmmF6dgT8wdSNVcDyY bXU3Iyydjtmqp4GTktKLL7FXdUdOZ0A= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1731616016; a=rsa-sha256; cv=none; b=loKbvTSDw7gWC+zqsaQvDK6loV/i77gp0TkWtD3qdzxL8BGA4ThfvqdDOMNAvfjYHiKr5W /Ouw6OJjcJb2OBoKL3l5MKKuXm4von0iFeHDE2h6hJw0N26Mmgb8/zTGgizJ0GLoYNvpLW 0FbkTyC3N0XMHA/6RWI9+zts+j72GgM= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=VIwLOOWN; spf=none (imf29.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=Z0aBHXXkP5UPuougQYO6Mqdo8Z0I9yuUFBmW3kdCRQI=; b=VIwLOOWNTr/hFIK4ugF6r0/zNM zu0kM6tGR8g68yFFVtexPAa18BSMR7KeNVo4bKMYdnJaNXWDt+8vdGL8Uhr8G0zk0abbMCvvL7Ot/ 637yX940TkoM/6Ve65QqndF8pXC1VqEY4l943v8VLfp+Rel+Ns1/GMCvH0VHh6N6hJxu9KBLeQizb Oci9dhVU4lw4JEYAaK8ruA00IsW2wJ+WvtHyZsr0h67wjTxD28lJPvVpi2zIMMF/Yz/I3AemdP6h6 P/aA/f5DBvMeRbKlwH/8PecFPwA6+uT+0QO7wfsKdB7CJ6Ma61GPRIpFW+0pbd59ELmk89W44CDLJ PT4JpGWw==; Received: from willy by casper.infradead.org with local (Exim 4.98 #2 (Red Hat Linux)) id 1tBgSs-00000000I41-2zrO; Thu, 14 Nov 2024 20:29:18 +0000 Date: Thu, 14 Nov 2024 20:29:18 +0000 From: Matthew Wilcox To: David Hildenbrand Cc: "linux-mm@kvack.org" , Yu Zhao Subject: Re: PageOffline: refcount, flags and memdesc Message-ID: References: <1239f9a1-81b7-4752-bfa4-d3ec9bd9118f@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1239f9a1-81b7-4752-bfa4-d3ec9bd9118f@redhat.com> X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 040D1120002 X-Stat-Signature: 3skyakcc6iwh8ons44zfpsnjitjbutem X-HE-Tag: 1731616099-483004 X-HE-Meta: U2FsdGVkX19sNFQcbHftuNcClOZNFIporxMBrf/dAowyJAL8+z8WMq2EfmK3HR9P+3RuuLKXWET5Ri/LHsplhh6priSZSGDvzyrrHRuwEl8NLwTeB6bs+frnOacODnradOa/y/FZ3r24B24k+Bbrtd/3VRVVKbC88oBwRIAr0d0ILCGmWLH8L472OkV9W5Y0kg1GKSfY6cjIfvIh2jdoj/eaYxEVc4xbcXzpGQ1M3H/8M+i9xbQPygP2fFpn9D3iTmeOfIsqrqlYiALMI51vcseayvT5+J8PmZ3YGgRqipswffRQ7NV2AgmjPnMZ+nGO0layaRyjx9SibhRGviRrBA+7oyqfT9+RPaIK3m22junCCqHE1ryo+t9i2mho+PM4wDATKhxlaLucyOP+GMbQ9OOi/U1bGpgnfaic6N2eo4Iccl1ln5Jo9MMB4MUorq7l4fmxHIFx42GX9rVhJ2rLe/YX9Uzzq+iVJ/Vk4rkFisWZ0EYPCs2HqZIVTs48+95ux063o7XfeZb8ucObBNnOzJTFmuzKNXHHT5GUlJfT9xCSH/bvh5sU9T4LByHE22WxgR/47fX3aQuBziIAh0yO8JrrYJkOx3GhiN6IC6MHf5U4S8GiCn2/biKtBopBp98Jx2fFOid2nlHfweIRa30PNiMjiKhUyZRb3aXh5K11L7oKGJG2yW952yDq4LdSmehfgiyTf2dObZxqr63Pd7iH8Eo8yoQUIgCZPgvRBFewNHsJ2kH/RvaQj+Q1110Wo74TJf6j440CSEX8acHskqgcHxXZRMv9lqyHJrL0yoFIGhpWLZu3iW657Mz7FsWmnhggttl4ejTyeB2ua4F7IpBgRRQ3w7CJGWSVjKggbF65ZbLJYWxk5bTnlWmkNVslSqsXlZMHsSVYB537+pfvb7Oy2ofmwJUDe7mkVeEe0hHISzzLkdxTp48dVrf7tFzgC3954incJ4d0Dnngo4F8qZ5 du8Mp01D noLSMm2jt5eKiseScrCGsNlNHVLdnOcqSr1BtyHGQgOgoWvaf89nfK3FDwYd76cF0nUnTwsdBPL5BjxeZ8eFI8C2k21907MyBsMXNZGtsVp58dLCv1cltpE5+z4JCwqoQzlHpBsWp2RuR1qluQgu39P7YxTBpYgBjUS+IBEzGjJZ3ROZT3hEQOr2DXB//lRQKbUEx1f/qgDd8bL3WTUSuMoSFORpVFa3WmlK5RciPbZrs2et9GUvcc9sYVksPNLEV068GvvrKCIejUplKshrfZ3AIz0r6ZJhsFOMNWIwl+aFoPMF4o7R7Btov4m3jNFK1eiPDWnGzw8binQRHtzjofCrxh1syQVHlRZsO 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 Thu, Nov 14, 2024 at 04:55:33PM +0100, David Hildenbrand wrote: > > Thanks for bringing it up. As a memdesc, I currently have PageOffline > > as being type 0 (Misc), subtype 5 (Offline). That's bits 0-10 and then > > bit 11 is for "may be mapped to userspace". Bits 12-17 are the order. > > With the top bits being used for section/node/zone, that could be 25 + > > 12 + 3 = 40 bits, so we'd have 7 bits remaining for use as flags. > > "may be mapped to userspace" will always be 0. 1 / 2 flags initially would > do. Yes, indeed, would always be 0 for Offline pages. Probably not for other pages though, and I'd like to have that property as a standard flag. > > > free_offline_page() > > > free_offline_page_range() > > > > > > And > > > > > > alloc_offline_page() > > > alloc_offline_page_range() > > > alloc_offline_pages > > > > > > I'm not super happy about the "alloc/free" terminology, but nothing better > > > came to mind. > > > > If I resurrect > > https://lore.kernel.org/linux-mm/20220809171854.3725722-1-willy@infradead.org/ > > would the frozen terminology work for you here? > > Ah, I remember that. > > I was more concerned about alloc/free terminology, because > "free_offline_page" could simply be "online_page" :) But the "allocation" > part is trickier. Maybe it's simply alloc/free of frozen pages for the time > being. > > But yes, the "allocate/free pages without involving refcounts" will be a > crucial thing to get the PageOffline conversion flying. > > Instead of alloc_frozen_pages(), I was wondering if we should have something > like GFP_FROZEN. For example, for two PG_offline users > I'd currently also need alloc_contig_frozen_range() and > alloc_contig_frozen_pages(). Using alloc_contig_range(GFP_FROZEN) > alloc_contig_pages(GFP_PROZEN) would make that easier. > > Did you consider that already? I think Yu Zhao's recent patches: e98337d11bbd ("mm/contig_alloc: support __GFP_COMP") 463586e9ff39 ("mm/cma: add cma_{alloc,free}_folio()") cf54f310d0d3 ("mm/hugetlb: use __GFP_COMP for gigantic folios") get us most of the way there. What I really want to do is make contig allocation not do anything with the refcounts. Hoist that into the callers which actually want it (probably not many), and then we can actually drop the __GFP_COMP support to alloc_contig_range_noprof().