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 3F8AFC30653 for ; Thu, 4 Jul 2024 15:52:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C85396B0085; Thu, 4 Jul 2024 11:52:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C35616B0088; Thu, 4 Jul 2024 11:52:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B23576B008A; Thu, 4 Jul 2024 11:52:21 -0400 (EDT) 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 91D0F6B0085 for ; Thu, 4 Jul 2024 11:52:21 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 4265AA4243 for ; Thu, 4 Jul 2024 15:52:21 +0000 (UTC) X-FDA: 82302512082.17.A7C8C5F Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf17.hostedemail.com (Postfix) with ESMTP id 5A60740013 for ; Thu, 4 Jul 2024 15:52:19 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=none; spf=pass (imf17.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1720108306; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ENpvSY3p3mdofElfqDDK1eIsDWFN8V4YTkfa2K9I8nI=; b=crJ6my1kOEtswXdzJO+i092FWgiutdxOhzaSMy9BVcOZhTxNEMSjGvd+3mAeqfydVIveNa I9iLaRG0jNYqI6Zq0camXA8xbDcs9tqw3U+3z5iHAw1xWIAFoOyWCheyBOP6VcEHdE/hhq jWSbL/Zbg407EkoMYJcAiFiVuwehpZU= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=none; spf=pass (imf17.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720108306; a=rsa-sha256; cv=none; b=FjKLzAHKMZ408WE6yHRF4HQffqSttQ+4fKCULX17VtYR3X3BMLf24WxCifhmvFLqB1OTDY EwH3Zoa5kNOdCciRTlPe1yQnF/aHFzFardXPuno/bFyUQG49BygJFQZEfoLz2TpOVESkqT EpzgMqcL/sgZvzr7tEx4mVKHmCHmONs= Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 51A45367; Thu, 4 Jul 2024 08:52:43 -0700 (PDT) Received: from [10.1.29.168] (XHFQ2J9959.cambridge.arm.com [10.1.29.168]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 45BC53F762; Thu, 4 Jul 2024 08:52:15 -0700 (PDT) Message-ID: <4b6ca560-03e7-4fd2-8b4b-acfc75bdb925@arm.com> Date: Thu, 4 Jul 2024 16:52:13 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v8 01/10] fs: Allow fine-grained control of folio sizes Content-Language: en-GB To: Matthew Wilcox Cc: "Pankaj Raghav (Samsung)" , david@fromorbit.com, chandan.babu@oracle.com, djwong@kernel.org, brauner@kernel.org, akpm@linux-foundation.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 References: <20240625114420.719014-1-kernel@pankajraghav.com> <20240625114420.719014-2-kernel@pankajraghav.com> From: Ryan Roberts In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 5A60740013 X-Stat-Signature: yx7pjrzu8wrip1qa37fxgrsqbmesybs6 X-Rspam-User: X-HE-Tag: 1720108339-640479 X-HE-Meta: U2FsdGVkX191XgycP3hEKi646sUoPu5opaZkSlT9O9s9tP/3zkIZ+bUjlcqYUDFaVNKPO2GyVlKqJiJQPB9UUr8sCa1T02/IbJpSwa1CKSF5IZtdSM/L4A5/VB4IsN57NjEpdzvhSAOaWtbPCHJPNl+FzPGZO2gs+ASFGBYjHxIgexmi6GRCR+P1f2s6R46okTNeyfYqamUbspgrkyf3kKL6rAITwFzI5YGYkirVfKHBeu51FJjGKQ67Y3pdmPClPB5RmolSZHCUSn1rTwdgla5sHlm2ltJfFu4XcGpkmiQWdaKhYrgVTbBzmg86m9LT+yxN5/k2y4lNRyBz13rr2Jgf8qc2IxqhljrTCuhdD4aSTjEEV2iHvm+IKHWg1hiZMb15o5+01ZszUt9SyK7Mi9ojdxjj5o+axuDEMm5VQYVx1utfq86N7Ew7ymY0+EnZsf1fQ65f+KpW9tRzx9OtQ8Bfi4CadRN3hKf0o+RKr5hIVtHalqlp2/kh3QNTnmE6tug9hpuPb7F+qCmiwPSBdXNCWwh2bq0djJRQOcjUsXZRum5Oxl2fWNLZZYJbl1ZHeR0QUtn0Z0/lj7Oj80oFyOwnyz4mSpHZyIu+Un8SRAkzTmr4gFA2pwzGKLqScrofN8Zt/oh9287EEsn2WBETLKGSsN189Tx6e52OU8w/udUv4DLGrqXDws8lez+YBKe2wwFyW7PwQ5ag+D6nh5TnkyvMx8TS9z+FRfqY7BvT9MiFYezZOUPjtm+mDOuCwPVf6fIFzQEHj6N60NmqrhIlDv0u8tJ9+eZUVxPiL5Wf+vtW/JLAcCfoCpWOaWXqBL1oUGCB4pba3fdiPJ3C9l+yD7obC3FaGHIm8CShdu69oiWaIEK8Wh/GfAtWFKVpveNOKMmkHEAM2bYn0pPCWoGpfLzQ82ksLSZ2QERyWVNGzqXHcnJkSXfjnmWr4ilKovCFrD018XLrQLIpjKefFMq Dx5sMjWy oaxc4avg7FG6419SkJN3Hy4SaArZIonKvygAr/aI8WUre7lbP7WFhf7ZdiVu1X1hjcnQL7azLb05U+R+QB5S4dEDky6yps02bKdTBXKzZ0ImT4Ibi98qb0wsDNS18pCYzQfkyCc9R+8t1gOX3zUchx9lC6S/p3jOgySKBJLRU74Oxh0Cg+2I+qMk+54mh+DBnVfIDSFFbU1a+70A= 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 04/07/2024 16:20, Matthew Wilcox wrote: > On Thu, Jul 04, 2024 at 01:23:20PM +0100, Ryan Roberts wrote: >>> - AS_LARGE_FOLIO_SUPPORT = 6, >> >> nit: this removed enum is still referenced in a comment further down the file. > > Thanks. Pankaj, let me know if you want me to send you a patch or if > you'll do it directly. > >>> + /* Bits 16-25 are used for FOLIO_ORDER */ >>> + AS_FOLIO_ORDER_BITS = 5, >>> + AS_FOLIO_ORDER_MIN = 16, >>> + AS_FOLIO_ORDER_MAX = AS_FOLIO_ORDER_MIN + AS_FOLIO_ORDER_BITS, >> >> nit: These 3 new enums seem a bit odd. > > Yes, this is "too many helpful suggestions" syndrome. It made a lot > more sense originally. Well now you can add my "helpful" suggestion to that list :) > > https://lore.kernel.org/linux-fsdevel/ZlUQcEaP3FDXpCge@dread.disaster.area/ > >>> +static inline void mapping_set_folio_order_range(struct address_space *mapping, >>> + unsigned int min, >>> + unsigned int max) >>> +{ >>> + if (!IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE)) >>> + return; >>> + >>> + if (min > MAX_PAGECACHE_ORDER) >>> + min = MAX_PAGECACHE_ORDER; >>> + if (max > MAX_PAGECACHE_ORDER) >>> + max = MAX_PAGECACHE_ORDER; >>> + if (max < min) >>> + max = min; >> >> It seems strange to silently clamp these? Presumably for the bs>ps usecase, >> whatever values are passed in are a hard requirement? So wouldn't want them to >> be silently reduced. (Especially given the recent change to reduce the size of >> MAX_PAGECACHE_ORDER to less then PMD size in some cases). > > Hm, yes. We should probably make this return an errno. Including > returning an errno for !IS_ENABLED() and min > 0. Right. > >>> - if (new_order < MAX_PAGECACHE_ORDER) { >>> + if (new_order < mapping_max_folio_order(mapping)) { >>> new_order += 2; >>> - new_order = min_t(unsigned int, MAX_PAGECACHE_ORDER, new_order); >>> + new_order = min(mapping_max_folio_order(mapping), new_order); >>> new_order = min_t(unsigned int, new_order, ilog2(ra->size)); >> >> I wonder if its possible that ra->size could ever be less than >> mapping_min_folio_order()? Do you need to handle that? > > I think we take care of that in later patches? Yes I saw that once I got to it. You can ignore this. > This patch is mostly > about honouring the max properly and putting in the infrastructure for > the min, but not doing all the necessary work for min.