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 21E73C3DA42 for ; Tue, 9 Jul 2024 17:33:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 696F96B008C; Tue, 9 Jul 2024 13:33:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6461C6B0092; Tue, 9 Jul 2024 13:33:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 534E06B0095; Tue, 9 Jul 2024 13:33:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 32B106B008C for ; Tue, 9 Jul 2024 13:33:18 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 80DE812052C for ; Tue, 9 Jul 2024 17:33:17 +0000 (UTC) X-FDA: 82320910434.17.73A8673 Received: from mout-p-201.mailbox.org (mout-p-201.mailbox.org [80.241.56.171]) by imf06.hostedemail.com (Postfix) with ESMTP id 42DC2180014 for ; Tue, 9 Jul 2024 17:33:14 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=pankajraghav.com header.s=MBO0001 header.b=xRzT21ty; spf=pass (imf06.hostedemail.com: domain of kernel@pankajraghav.com designates 80.241.56.171 as permitted sender) smtp.mailfrom=kernel@pankajraghav.com; dmarc=pass (policy=quarantine) header.from=pankajraghav.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720546380; a=rsa-sha256; cv=none; b=nphGstMpiVFqaf2gfcDpdNDjcta5D0e2j25p2qZ8dvpICIPoWMnqM8fZl1RkwVowE1fNUI 7jTas+Pa7cS/dF849ZArbNlVwzicHPOmq+SZpZh6j+Z/3x4Jleh9v3PAj5M6EbnYKRaRgI 43nURpn4TTKxj/KDuh6qHUp1zVhJl5g= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=pankajraghav.com header.s=MBO0001 header.b=xRzT21ty; spf=pass (imf06.hostedemail.com: domain of kernel@pankajraghav.com designates 80.241.56.171 as permitted sender) smtp.mailfrom=kernel@pankajraghav.com; dmarc=pass (policy=quarantine) header.from=pankajraghav.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1720546380; 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=otfm4nHuOCKVaItEE8eENwKYWnrlA+AT8ngghD3F3L4=; b=7MR2cWKh5PTgOKHjgt3nUZu5jVBPaS1KLFv3Hd3ogKMixgIXw5EdPPCTAS5Q+nLYqvN5Zu erHR/OmSjYePjcLvbannZcl0w5b3Xlku84f1kpk9suxDRfF1LHy5tF12hhj1EK+oAG21lK rFoD7KpkDVEPhyOpiC9OEeCzo9BXxko= 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-201.mailbox.org (Postfix) with ESMTPS id 4WJSkZ1hfCz9sRn; Tue, 9 Jul 2024 19:33:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pankajraghav.com; s=MBO0001; t=1720546390; 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=otfm4nHuOCKVaItEE8eENwKYWnrlA+AT8ngghD3F3L4=; b=xRzT21tyRcASI0eQu22uFyLR34eYoEgDyWGw9mNDmWbUU19vbgvCF4NPSvzMJzm0KASsE0 ngMaRu29aTevKrpoLqeVn4XSTNLiSWOpWiVDnTdpQvAs8N0qnENPWdqrjFx+bBE1R4sirp 42fC/aYNhDAIPdFPmGs7exdty1NNYomPB8ldxGbraDzcFsVhbzIiyBlePiWqB4OZ7jB73E gvf7QptuHX+XhEuI/PsWozith2J81Uy/MfiLt8LdX8ia8QmeXkpWSsrDJbbzotn3mqU8bi RZKMiDy5yoqjN3fh8qJel/vrug1AjhLq5C2ci3aoPElDMDtlPN7eHvKQMqv4Ow== Date: Tue, 9 Jul 2024 17:33:05 +0000 From: "Pankaj Raghav (Samsung)" To: Matthew Wilcox Cc: david@fromorbit.com, ryan.roberts@arm.com, djwong@kernel.org, linux-kernel@vger.kernel.org, yang@os.amperecomputing.com, linux-mm@kvack.org, john.g.garry@oracle.com, linux-fsdevel@vger.kernel.org, hare@suse.de, p.raghav@samsung.com, mcgrof@kernel.org, gost.dev@samsung.com, cl@os.amperecomputing.com, linux-xfs@vger.kernel.org, hch@lst.de, Zi Yan , akpm@linux-foundation.org, chandan.babu@oracle.com Subject: Re: [PATCH v8 01/10] fs: Allow fine-grained control of folio sizes Message-ID: <20240709173305.gb3ffmlja72ypgsd@quentin> References: <20240625114420.719014-1-kernel@pankajraghav.com> <20240625114420.719014-2-kernel@pankajraghav.com> <20240709162907.gsd5nf33teoss5ir@quentin> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: ujbcdi56aotwwswkkgaek5rycg7ycybc X-Rspamd-Queue-Id: 42DC2180014 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1720546394-22802 X-HE-Meta: U2FsdGVkX1+cvNtdorWH7bl3gfb+D2wVju7nqgOtG0v2WRa8oT/J4AOKALTTt+vWnwnHLXo1jDSI1+kXFMUQj4N5WGoRscRfLdgmMn2DiLNEqY3onlKJ2RhFtFPw5PjIvs2ipVtyGuWsorvLNbpxuZqy7P0ZV+/rIfMyLrlNTMeTXApVjPl7JDg9XjEl94GdJJn/5KFcOiLvR/k9qcew+Sq7gy3P3Z6NnZYvVDyrAsrviLUhdb/EEkTI2pFdAZXynlfdpq+XTgeWvOlZ3xKio41GiBGtueR2LCPyy0QW6v9kq+/FDEgw6/AadDYYbV0KIgDPVcXAGO6Qawixp7bKI6VN0ZvnXmzMxzdlKd6DGNp/BVIr344xylQGyEPqA45zfLrl1vNUFvuPHBuxCSOmCAVcKKOuL4Z6E+N01Uaabr1X7FvWXW9wJEaRqDu4yAYZGQ13plv8T9vXFIf6jwKUlAlAKew6BCbbH+rYB+J7zLgmyAmqMIqHyr3NH500cvTy51p9eRCj6Er0CNY3oswjZRlHHcejaeLKS42uSrT9xXSc5jGd55Pxtp0r7GyYRMmZTSfK6x/IH3TAcGEsnN3P2sJtSa9HCO0vqlYMCec435RiS3x0B049GrewB+8+kLhx7mJC+6z5ix/RQfFxqe1xraRIBGqNTRX8DE+7JBRstnq218SASnqH4yHYZ9GiIxZJS6tW54RtOEyJJ3mA+4Muvu6a7cEz57hlR1gHTa2OqMLikNT/f5iSWAiT5taBzBs3vf08UrpfbPtOdaa/rRGL0gGoy00dF7PUgdeTjjNrjL+IH3YfbtZb9dpZx/+sICMSGS9ooh5T8pSgGYBsMPvA1D9DqWVIAtZpr4OLtwcp6C0LVgF8VVXbgWhEkFhJM3VWj7iKWsPCsuaOk+qUOPusuourjvUc6xg98EgF518qqCbicFFBGvS1GXwx5Aa6uh9zbhYkfZcLGW9M28jA9yq 1QnEkcvA Aqy0pdYqWhm2JtvbuNn2/bc0vVJFQc4mLHv+VTK3u2wSgG6utcqj81j96F38c2UBLHxesy3ZzOxwo6szt9Jzxp3HehCA+VATHtZDx83qHERte5sD88c5yElL9Ud5czc2OKODK+QnzSXYZGOu6rQHxGTxInN+txU8J1lmD0sLZ8p6JqUyugFaRMdtQO0ml5yiMZj7T1UUoK/Pwc8oBD42H6LXtIPMRhDhxtFS5 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 Tue, Jul 09, 2024 at 05:38:16PM +0100, Matthew Wilcox wrote: > On Tue, Jul 09, 2024 at 04:29:07PM +0000, Pankaj Raghav (Samsung) wrote: > > +++ b/include/linux/pagemap.h > > @@ -394,13 +394,24 @@ static inline void mapping_set_folio_order_range(struct address_space *mapping, > > unsigned int min, > > unsigned int max) > > { > > - if (!IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE)) > > + if (!IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE)) { > > + VM_WARN_ONCE(1, > > + "THP needs to be enabled to support mapping folio order range"); > > return; > > + } > > No. Filesystems call mapping_set_folio_order_range() without it being > conditional on CONFIG_TRANSPARENT_HUGEPAGE. Usually that takes the > form of an unconditional call to mapping_set_large_folios(). Ah, you are right. Actually thinking more about it, we don't need VM_WARN_ONCE on CONFIG_THP IS_ENABLED, because if we go the route where a FS will call something like `mapping_max_folio_order_supported()` during mount time, that will already return `0` as the maximum order that will be supported. So just something like this should be enough: diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h index 14e1415f7dcf..ef6b13854385 100644 --- a/include/linux/pagemap.h +++ b/include/linux/pagemap.h @@ -397,10 +397,18 @@ static inline void mapping_set_folio_order_range(struct address_space *mapping, if (!IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE)) return; - if (min > MAX_PAGECACHE_ORDER) + if (min > MAX_PAGECACHE_ORDER) { + VM_WARN_ONCE(1, + "min order > MAX_PAGECACHE_ORDER. Setting min_order to MAX_PAGECACHE_ORDER"); min = MAX_PAGECACHE_ORDER; - if (max > MAX_PAGECACHE_ORDER) + } + + if (max > MAX_PAGECACHE_ORDER) { + VM_WARN_ONCE(1, + "max order > MAX_PAGECACHE_ORDER. Setting max_order to MAX_PAGECACHE_ORDER"); max = MAX_PAGECACHE_ORDER; + } + if (max < min) max = min; If we have a helper such as mapping_max_folio_order_supported() that could be invoked by FSs to see what page cache could support. And FSs that call mapping_set_large_folios() as an optimization will not see these random WARNINGS because we call this function with the actual min and max range. Let me know what you think. -- Pankaj