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 BE6B7C25B7C for ; Tue, 28 May 2024 10:20:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5AD1A6B008A; Tue, 28 May 2024 06:20:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 55D456B008C; Tue, 28 May 2024 06:20:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 424BA6B0092; Tue, 28 May 2024 06:20:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 25D626B008A for ; Tue, 28 May 2024 06:20:47 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id D92811A04BF for ; Tue, 28 May 2024 10:20:46 +0000 (UTC) X-FDA: 82167410892.21.2BCF50E Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by imf30.hostedemail.com (Postfix) with ESMTP id 930AB8001E for ; Tue, 28 May 2024 10:20:44 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b="ZdJK/WJS"; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=XnYitsrG; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=0gXaoKLd; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=uNCD0nT1; spf=pass (imf30.hostedemail.com: domain of hare@suse.de designates 195.135.223.130 as permitted sender) smtp.mailfrom=hare@suse.de; dmarc=pass (policy=none) header.from=suse.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1716891644; 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:dkim-signature; bh=tF7PC65/Wxvqm7PDuhbYG43Mw/LteX4wRnY8H+kpTw4=; b=wsou8bnxp+U8fNilOR5HfgvPPApJd6b0pdZ8srzj20hxxQgn61iYeOVDfwWjiqr++weax1 AAkwsdpdk90YjudLVwmHiVj7h+7eMSxRqzEZES3mR31WZw+AB/1YDz1vdS8S9L2t/+2Sz6 AHXoFoppaJrn/Mms5g3yOaCmZkoN94A= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1716891644; a=rsa-sha256; cv=none; b=fuV9bUNe4mh0vR9A3uZpIb0BrIR6eVzWLZhUHToQftp8teGuFrXbU4NjuzAgPV5C2twShI 6hSBEZz9gwa2e0aQSRmxnsM9DRwMewGnHeZC1x9FCkwpQIT/WkXcgpbvgyaDysuHU2RjGF kvC8jBlnMkDULlYzeNnVe+JkQ1epWUQ= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b="ZdJK/WJS"; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=XnYitsrG; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=0gXaoKLd; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=uNCD0nT1; spf=pass (imf30.hostedemail.com: domain of hare@suse.de designates 195.135.223.130 as permitted sender) smtp.mailfrom=hare@suse.de; dmarc=pass (policy=none) header.from=suse.de Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97]) (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 smtp-out1.suse.de (Postfix) with ESMTPS id EC71A21F4C; Tue, 28 May 2024 10:20:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1716891643; h=from:from:reply-to: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=tF7PC65/Wxvqm7PDuhbYG43Mw/LteX4wRnY8H+kpTw4=; b=ZdJK/WJSpXcfvUt0kpyNWmINdEif0Fr478qdCL1v1GIOG62PwQ5vHfl24GGdssilDzV/Lk 1vSnCLrILzbJiOotPBiWm5F//PEOXUSYth/BWcbmcbiIE/LAnfUtQwR30OM7cBLcmptHwx kMKFuQ/Qw2NTGFuyQH+EcigFZ496hYA= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1716891643; h=from:from:reply-to: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=tF7PC65/Wxvqm7PDuhbYG43Mw/LteX4wRnY8H+kpTw4=; b=XnYitsrGa/X9LuBEbrJE+PuGz5zrCERrg6/pvdKXpDJ8YEm6/UKx7GZRbgINWxyf3hYPgQ luo+rSfVTrdNprBA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1716891642; h=from:from:reply-to: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=tF7PC65/Wxvqm7PDuhbYG43Mw/LteX4wRnY8H+kpTw4=; b=0gXaoKLdzVWsVhHZwyAFekXJ4Y+Y+Vx4BYr/OzQkJlU+O84hqXijJbgdeCqUyTYthIZdTd wAD3RDQsusVyYOAG4fuiwLMbFEd5Ww9Ye7Z6PRW+YgF6LsmKmKyOYJsY+ZP68N4KfhSNh8 hICNyC5Pc3OUAA4WX2uz39qd54rdrMY= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1716891642; h=from:from:reply-to: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=tF7PC65/Wxvqm7PDuhbYG43Mw/LteX4wRnY8H+kpTw4=; b=uNCD0nT1sE8t+O1QCtfERGEDDDbGLorLqe/XZMBMdES1dOGxR3w5oj0m0TmzCpQXCNcTvc 10kld8GBrUc7o4BQ== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (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 imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 786D613A6B; Tue, 28 May 2024 10:20:42 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id a8mLG/qvVWZ3DQAAD6G6ig (envelope-from ); Tue, 28 May 2024 10:20:42 +0000 Message-ID: Date: Tue, 28 May 2024 12:20:41 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5.1] fs: Allow fine-grained control of folio sizes Content-Language: en-US To: "Matthew Wilcox (Oracle)" , akpm@linux-foundation.org, djwong@kernel.org, brauner@kernel.org, david@fromorbit.com, chandan.babu@oracle.com Cc: ritesh.list@gmail.com, john.g.garry@oracle.com, ziy@nvidia.com, linux-fsdevel@vger.kernel.org, linux-xfs@vger.kernel.org, linux-mm@kvack.org, linux-block@vger.kernel.org, gost.dev@samsung.com, p.raghav@samsung.com, kernel@pankajraghav.com, mcgrof@kernel.org References: <20240527210125.1905586-1-willy@infradead.org> From: Hannes Reinecke In-Reply-To: <20240527210125.1905586-1-willy@infradead.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 930AB8001E X-Rspam-User: X-Stat-Signature: qwxpx773n1ydicejmyeymsui615eu9yc X-HE-Tag: 1716891644-674312 X-HE-Meta: U2FsdGVkX19+u1/y6QXc/6qfzWcoPzL4286BLaVKgmSZ6Rpx+j2gSedvOt5/W+15APfK6G0zboNiFLh4Pw+LsVEfdvLDTq/GgF8sZZ83PdeQd/fA+t1EFTRjPPgSGOUTVmZpfGxuTnnCM0tr3/23tKRRMHMPJO7GsT64GiOVLJKQ2LDsu774aOIh2ElXjvN0vkzb3215GiwxyjTDlyIx69QNSGVBLtTwqNm6HFUsaYj+zbIBYgyRKwzV+kzj5AzBUbltIFSO1sVKvBTV7dx/7R7zdCNosZu8fln8Bae7h71tsM8dwclrFxq8DJhUzdQAFY/TpfQB02Sq4uutf3IKIMOSJG5xUYSRRYFWZgFa/g3+HqDwqUWDgxWruMBGfBHL3fLQASJNO89OhBJIa1ZFjp7UrD5tVAocmkWkDMUXPaB2kOil+LCDTlHj4GEyBrli/J6sbbICEHdjXZ78LZjeoJYCOHCa0rD6JayJs1yNG979VK102L3CObX08v1f2BdpiADmOdDg1jsHlo85kcgBZtbQZvt0ocFjXOIN39zTYxtsJlEcVlnxzf/7GyaNti6LnpvLXoDHzTTsOK+YnHLx5PS4tUsZUt9K98JITvukFxEC98EnBzJif3Pc58pF1QmXEltiVyH4yQHsfGvyS5uIKxTJJeLRuJ7DSk5MSn0CMtuv9SjGq4cE6NB9fK6cw47EYWCjlFwDOE7z7pH4xXRfXaQq5rtvrcxobQrU5W4IxqspYBcY9PuBrByNZeN8gWnulZ4fzfTsDeoiXsTmJkHFEAbU1ACEHQi1z/iU6+2Nt9U6XILXYKvrmlEmT8ZkPr4K7+ibW/gvMkdY8TJfNUNYfmlseqnso/fVbTagx60sMUnUt+vd2eog8jaKWo2BDdsRrLrfUof63DXKC/2nTqIgNYKtVmOwxpIhiq2LIoifmXFFEtDxSxaXXjK1JZkSotCGm7IHfX+W6nSNFdaneas AMk3PM3G P+9NOd1yzq1zOoUOYQxrB2/uITXjUPSEwCFhYfS7T8d20ofpe2s0QQ3b9M8w0Vy/s0L04I4CNajqjJ1vKu+zty8OuNfwl8RQs9JKQ4a7ay5XPyZUNeXZCB88KG8bN4XnS8ebLkNjZoURkyQqPv6TcgfstLc61uHe7sJWPlKj8gBxRRGqDoBIeg8Ipv6SO5VHUYwoaPIogE+Fb1Ed2NWxEi1Un7S3+8BSOeovfkpIq7rKTGBf9ZnSNN85wsEBZylkBow5r6AyWFE/DJm/4FRjd5ajkoUZSiyvaiS0dEn7VP7T0OoRBTtbNicMIC/Ff9b0TISYUUz3unJoLXxKOnD760qKMos9Ym5c9D5a16FM5POt1HQoFUkEFVye03N7g3+lueWsURKHJZl4PEZ9P5W//TKmM0gm2iWiN2aKZBDTp9uyqIV7j33avE7oYBRCpxccC6WW4z78jAd32PahyoVIhbwInzgvYnuoGNXE22/S/DZLLlaPxsiqcBPtlp5KVhQdsOegh2uEOIXSTpv5Wha6ac7FJEA== 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 5/27/24 23:01, Matthew Wilcox (Oracle) wrote: > We need filesystems to be able to communicate acceptable folio sizes > to the pagecache for a variety of uses (e.g. large block sizes). > Support a range of folio sizes between order-0 and order-31. > > Signed-off-by: Matthew Wilcox (Oracle) > Co-developed-by: Pankaj Raghav > Signed-off-by: Pankaj Raghav > Reviewed-by: Darrick J. Wong > Reviewed-by: Hannes Reinecke > --- > For this version, I fixed the TODO that the maximum folio size was not > being honoured. I made some other changes too like adding const, moving > the location of the constants, checking CONFIG_TRANSPARENT_HUGEPAGE, and > dropping some of the functions which aren't needed until later patches. > (They can be added in the commits that need them). Also rebased against > current Linus tree, so MAX_PAGECACHE_ORDER no longer needs to be moved). > > include/linux/pagemap.h | 81 +++++++++++++++++++++++++++++++++++------ > mm/filemap.c | 6 +-- > mm/readahead.c | 4 +- > 3 files changed, 73 insertions(+), 18 deletions(-) > > diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h > index 1ed9274a0deb..c6aaceed0de6 100644 > --- a/include/linux/pagemap.h > +++ b/include/linux/pagemap.h > @@ -204,13 +204,18 @@ enum mapping_flags { > AS_EXITING = 4, /* final truncate in progress */ > /* writeback related tags are not used */ > AS_NO_WRITEBACK_TAGS = 5, > - AS_LARGE_FOLIO_SUPPORT = 6, > - AS_RELEASE_ALWAYS, /* Call ->release_folio(), even if no private data */ > - AS_STABLE_WRITES, /* must wait for writeback before modifying > + AS_RELEASE_ALWAYS = 6, /* Call ->release_folio(), even if no private data */ > + AS_STABLE_WRITES = 7, /* must wait for writeback before modifying > folio contents */ > - AS_UNMOVABLE, /* The mapping cannot be moved, ever */ > + AS_UNMOVABLE = 8, /* The mapping cannot be moved, ever */ > + AS_FOLIO_ORDER_MIN = 16, > + AS_FOLIO_ORDER_MAX = 21, /* Bits 16-25 are used for FOLIO_ORDER */ > }; > > +#define AS_FOLIO_ORDER_MIN_MASK 0x001f0000 > +#define AS_FOLIO_ORDER_MAX_MASK 0x03e00000 > +#define AS_FOLIO_ORDER_MASK (AS_FOLIO_ORDER_MIN_MASK | AS_FOLIO_ORDER_MAX_MASK) > + > /** > * mapping_set_error - record a writeback error in the address_space > * @mapping: the mapping in which an error should be set > @@ -359,9 +364,48 @@ static inline void mapping_set_gfp_mask(struct address_space *m, gfp_t mask) > #define MAX_PAGECACHE_ORDER 8 > #endif > > +/* > + * mapping_set_folio_order_range() - Set the orders supported by a file. > + * @mapping: The address space of the file. > + * @min: Minimum folio order (between 0-MAX_PAGECACHE_ORDER inclusive). > + * @max: Maximum folio order (between @min-MAX_PAGECACHE_ORDER inclusive). > + * > + * The filesystem should call this function in its inode constructor to > + * indicate which base size (min) and maximum size (max) of folio the VFS > + * can use to cache the contents of the file. This should only be used > + * if the filesystem needs special handling of folio sizes (ie there is > + * something the core cannot know). > + * Do not tune it based on, eg, i_size. > + * > + * Context: This should not be called while the inode is active as it > + * is non-atomic. > + */ > +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; > + Errm. Sure? When transparent hugepages are _enabled_ we don't support this feature? Confused. Cheers, Hannes -- Dr. Hannes Reinecke Kernel Storage Architect hare@suse.de +49 911 74053 688 SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich