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 2CBD8C71135 for ; Mon, 16 Jun 2025 10:41:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6FDC66B0088; Mon, 16 Jun 2025 06:41:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6AE516B0089; Mon, 16 Jun 2025 06:41:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5C3F06B008A; Mon, 16 Jun 2025 06:41:49 -0400 (EDT) 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 4B8C96B0088 for ; Mon, 16 Jun 2025 06:41:49 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id E40A15E6DF for ; Mon, 16 Jun 2025 10:41:48 +0000 (UTC) X-FDA: 83560923096.16.7BD9124 Received: from mout-p-102.mailbox.org (mout-p-102.mailbox.org [80.241.56.152]) by imf19.hostedemail.com (Postfix) with ESMTP id EFFBF1A000A for ; Mon, 16 Jun 2025 10:41:46 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=pankajraghav.com header.s=MBO0001 header.b=PtBEAxVo; dmarc=pass (policy=quarantine) header.from=pankajraghav.com; spf=pass (imf19.hostedemail.com: domain of kernel@pankajraghav.com designates 80.241.56.152 as permitted sender) smtp.mailfrom=kernel@pankajraghav.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750070507; 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=5oSk0eziRiPQxIm2xpJSi+rzCVxixCf2/SUD1VuuXvA=; b=raTPqj56ltSj44QFi9GpTJWU4CWYXSarNWXbgdylOgzXdo0jUykQjWrGIVOZHcUGwzVIaS v6Zbbo/M7xu6bMkZGgHWJNw/MnJH8Bg0PQFUia6+vY/XRFTJVyDbtW+m4n7VJHsjHnLn45 cjYIX0PbA3PUlRxSOAT5EcZHZwBTzj4= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750070507; a=rsa-sha256; cv=none; b=r3dE3o+yAdTWukIL3uaYiQ04nmTbpLqNCTqWmNp/t0Fd7pA+ptIfIMOB9/GQTrvWqSiU4h b2D4Yqv+M8qLC7ZUag/S6PwnH6xVYl/Xc2D1iY6tDPJCHAaF7ez2jSC8HPemWNqcvHkQfA MzU7ivjLj3vQ3xwvNW/7uVZOV/iKu3s= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=pankajraghav.com header.s=MBO0001 header.b=PtBEAxVo; dmarc=pass (policy=quarantine) header.from=pankajraghav.com; spf=pass (imf19.hostedemail.com: domain of kernel@pankajraghav.com designates 80.241.56.152 as permitted sender) smtp.mailfrom=kernel@pankajraghav.com Received: from smtp102.mailbox.org (smtp102.mailbox.org [10.196.197.102]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-102.mailbox.org (Postfix) with ESMTPS id 4bLRPy4Xyfz9sNv; Mon, 16 Jun 2025 12:41:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pankajraghav.com; s=MBO0001; t=1750070502; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=5oSk0eziRiPQxIm2xpJSi+rzCVxixCf2/SUD1VuuXvA=; b=PtBEAxVon6X+5TauyCHml0gSVf0/dK0Bz09Z5ym8rKg8H0PYZ0URJ2w6F67+4+9YsFlBbj 2uqpgH2adVdkOzlaFbsakNOPFL//WXshXak1la9GF6kJZzioWFauDyUmTXiQq3gm9Bb7e4 OX3Lv8MiZ+P5Q1prPdc6ZBk0Bf/U++79fnNB8SFUNatFwc/owqStWtcOjYtcq5Of1BHCAG jTVDO6nrqSYc+xd6t2OIpVGjyNy7POqsgHeexXChHIZp+jVRhcqyjGVph/fPLxYFA5ta/z j5ZwBcoaSXf5cO5A55o6PN7HSajou51Pgas4/J5heggkVtC13NIjOxpoN9msow== Date: Mon, 16 Jun 2025 12:41:30 +0200 From: "Pankaj Raghav (Samsung)" To: David Hildenbrand Cc: Dave Hansen , Pankaj Raghav , Suren Baghdasaryan , Ryan Roberts , Mike Rapoport , Michal Hocko , Thomas Gleixner , Nico Pache , Dev Jain , Baolin Wang , Borislav Petkov , Ingo Molnar , "H . Peter Anvin" , Vlastimil Babka , Zi Yan , Dave Hansen , Lorenzo Stoakes , Andrew Morton , "Liam R . Howlett" , Jens Axboe , linux-kernel@vger.kernel.org, linux-mm@kvack.org, willy@infradead.org, x86@kernel.org, linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org, "Darrick J . Wong" , mcgrof@kernel.org, gost.dev@samsung.com, hch@lst.de Subject: Re: [PATCH 4/5] mm: add mm_get_static_huge_zero_folio() routine Message-ID: References: <20250612105100.59144-1-p.raghav@samsung.com> <20250612105100.59144-5-p.raghav@samsung.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: EFFBF1A000A X-Stat-Signature: ordjrq47n9i4b7egdfbzjb4m54uxy3n8 X-Rspam-User: X-HE-Tag: 1750070506-132846 X-HE-Meta: U2FsdGVkX1+lHj9dfhcIEie4fMWLKMOo1je5+bmirumLwroSkC/xCy5kPwEUPtWFPk+fTvKx+PY7PGGspziR+xpEfY3S0l2XFcL/il/8mbAMR4prvGEWgc8Ddl8Lbu4RLGanhYgMoWTg+sR4Mk09z8/Knt50LsB8UHyaz/tzahSeuHeFwhLCzj1FC1cMl0IIVkxAktEJEGOVP4U9x+JtD9ufGqGQIRH74o83ZitSoOpJdZCTLZdHtBSPBvhvEFHu+5bnwmZZEUQ25ORQH7LQOkgEi4RLBJHB07tk07Hpr3u2Sd1AJa7swZijgBtvJMYg88oIaHnbRbTlYe3sUdRySPmXXB7LQWTigJaDwgkL82F7fvKJ46JFzDCQAEveV3Q/+oLF9Iu6Ut01S/RtjMuZAvUaGtE11mAY8qeU39di0igya8Mf693iPq7nY7eAKrXT7NEFKgYWS9E9c4k/yvHw5xpB+KkX8J2T55Qk1A6c40Uha75cqlJ5FwFiUucqsSPmRUM8ZF61yGIxxfiMHDOBQaOnmXo3TJaSYwvZT7CLt9deEyKZE/utyMhlsfwYYNu5ZV4wAph9c4eGTR5ko5vmH0DuZOqPltX4ZKAI9MVtQkWqHzWBz1uyLcIKZZ8BLNciy0sMnn1Xfib1X5V8YUAbZ0DqEMj3xckhmBik91M4G0zuPNwJ70THDXD1FVQuQgJ4EIwfEWDOOAOEN3pfhJRL517KqGwdkcKqNerGeoeF538slP0KNz1htKTqEG8rEtAACQf7OS1HQ8UD2nNs4rOcYgs0NO/rs15zcT98mRxFP0zIWHUUaYLZwTVzljv+fvyIyOxLsQR6bPGqn9iQThJPe6I6ma1+o7PJ3+Ms1+rJPgWQEvw4noLjUX1fzivsTEF0+ROGmUrh8Qe5HnjQPO+T8hGnvtCtHEAdzl6ljtQUpdObbaXXdANdEJiQftWgFSB1fdcAW+tVZB2AnyPOO2M LwaiztP+ /giGDQAIlIQceMtHB2ipwSSJoLhAdjGTEChxMyLHXV55glBezOhO1/LGJ8f0DUHyowdlHXOdf32a8t1ETg58A0ZEKMf9n+aatIO1PYQjPYKf/0ZKSu26HRzaqAaIKCbnOg6tn9uENQLk/i6rnsdtvlyS6eQ1rn48qFdzVPUkn8zoIEsRIH8RHgdO4yLNvu87kosBnPP/5oMvj1xgYv9nQtiB+tlynjXopVIrI+vyC5fKYaudxAY4aTEDmRGh/k5S3x7F2DNG8OFJPKFwYbHUCqD2acZzMiDIAdMsH/OIWCCiqNDUVcEBumyv7GvnF/XpnjCVH99eJ4NF8re4= 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, Jun 16, 2025 at 11:14:07AM +0200, David Hildenbrand wrote: > On 12.06.25 22:54, Pankaj Raghav (Samsung) wrote: > > On Thu, Jun 12, 2025 at 07:09:34AM -0700, Dave Hansen wrote: > > > On 6/12/25 03:50, Pankaj Raghav wrote: > > > > +/* > > > > + * mm_get_static_huge_zero_folio - Get a PMD sized zero folio > > > > > > Isn't that a rather inaccurate function name and comment? > > I agree. I also felt it was not a good name for the function. > > > > > > > > The third line of the function literally returns a non-PMD-sized zero folio. > > > > > > > + * This function will return a PMD sized zero folio if CONFIG_STATIC_PMD_ZERO_PAGE > > > > + * is enabled. Otherwise, a ZERO_PAGE folio is returned. > > > > + * > > > > + * Deduce the size of the folio with folio_size instead of assuming the > > > > + * folio size. > > > > + */ > > > > +static inline struct folio *mm_get_static_huge_zero_folio(void) > > > > +{ > > > > + if(IS_ENABLED(CONFIG_STATIC_PMD_ZERO_PAGE)) > > > > + return READ_ONCE(huge_zero_folio); > > > > + return page_folio(ZERO_PAGE(0)); > > > > +} > > > > > > This doesn't tell us very much about when I should use: > > > > > > mm_get_static_huge_zero_folio() > > > vs. > > > mm_get_huge_zero_folio(mm) > > > vs. > > > page_folio(ZERO_PAGE(0)) > > > > > > What's with the "mm_" in the name? Usually "mm" means "mm_struct" not > > > Memory Management. It's really weird to prefix something that doesn't > > > take an "mm_struct" with "mm_" > > > > Got it. Actually, I was not aware of this one. > > > > > > > > Isn't the "get_" also a bad idea since mm_get_huge_zero_folio() does its > > > own refcounting but this interface does not? > > > > > > > Agree. > > > > > Shouldn't this be something more along the lines of: > > > > > > /* > > > * pick_zero_folio() - Pick and return the largest available zero folio > > > * > > > * mm_get_huge_zero_folio() is preferred over this function. It is more > > > * flexible and can provide a larger zero page under wider > > > * circumstances. > > > * > > > * Only use this when there is no mm available. > > > * > > > * ... then other comments > > > */ > > > static inline struct folio *pick_zero_folio(void) > > > { > > > if (IS_ENABLED(CONFIG_STATIC_PMD_ZERO_PAGE)) > > > return READ_ONCE(huge_zero_folio); > > > return page_folio(ZERO_PAGE(0)); > > > } > > > > > > Or, maybe even name it _just_: zero_folio() > > > > I think zero_folio() sounds like a good and straightforward name. In > > most cases it will return a ZERO_PAGE() folio. If > > CONFIG_STATIC_PMD_ZERO_PAGE is enabled, then we return a PMD page. > > "zero_folio" would be confusing I'm afraid. > > At least with current "is_zero_folio" etc. > > "largest_zero_folio" or sth. like that might make it clearer that the size > we are getting back might actually differ. > That makes sense. I can change that in the next revision. -- Pankaj