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 X-Spam-Level: X-Spam-Status: No, score=-3.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id ADF33C432BE for ; Wed, 1 Sep 2021 09:41:13 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3BC7C60F3A for ; Wed, 1 Sep 2021 09:41:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 3BC7C60F3A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 9AB2D6B006C; Wed, 1 Sep 2021 05:41:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 95B5D6B0071; Wed, 1 Sep 2021 05:41:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8494D8D0001; Wed, 1 Sep 2021 05:41:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0002.hostedemail.com [216.40.44.2]) by kanga.kvack.org (Postfix) with ESMTP id 75B706B006C for ; Wed, 1 Sep 2021 05:41:12 -0400 (EDT) Received: from smtpin40.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 211EC26819 for ; Wed, 1 Sep 2021 09:41:12 +0000 (UTC) X-FDA: 78538511184.40.339AF77 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf21.hostedemail.com (Postfix) with ESMTP id AD737D022F79 for ; Wed, 1 Sep 2021 09:41:11 +0000 (UTC) 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=6TBF+qXplc9oeCUOY+UjwCh+LIVpyFyk42tsJE47zzc=; b=dqWKrOMNN3eJvo4aHYae9gFmrM VyRA/uIp3lROX+RFWQcbkLXz1Yaq8CegwdNirdWf8U5rc7Xpl89yG3I+Bt62r5ZvXxtfsLcZE22A7 p+1xifRCxwXZCOsiYJYIf8QCK0z4OYBu7VxfZtTyYozz8bRZzXWUfcn2zZ5OHwU1nQ5HwDziiqk7w 0Tdjlch7I2luiDWTEgPDVYgFIkEdWUB4+cCi9GZq+x7saZ53dzYG1n/6MbSX5LD4kJuDIxOj1xXOO SQEuEIWDWWVS10gBOnie2RpN83bbzf2kM8dZXNbyZVz6gJqaz28y1BDv9jtCIHNgAdwRd2o3wDCU7 SfPmfJ1A==; Received: from hch by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1mLMj3-0026bK-LF; Wed, 01 Sep 2021 09:40:18 +0000 Date: Wed, 1 Sep 2021 10:40:09 +0100 From: Christoph Hellwig To: Matthew Wilcox Cc: Johannes Weiner , "Darrick J. Wong" , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: Discontiguous folios/pagesets Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-SRS-Rewrite: SMTP reverse-path rewritten from by casper.infradead.org. See http://www.infradead.org/rpr.html Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=dqWKrOMN; spf=none (imf21.hostedemail.com: domain of BATV@casper.srs.infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=BATV@casper.srs.infradead.org; dmarc=none X-Stat-Signature: 9rt5hp6j3mfqxuxeew9btnr7qsrgwaxb X-Rspamd-Queue-Id: AD737D022F79 X-Rspamd-Server: rspam04 X-HE-Tag: 1630489271-140388 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: On Sat, Aug 28, 2021 at 08:04:15PM +0100, Matthew Wilcox wrote: > Non-power-of-two folios are more awkward. Any calls to folio_order() > and folio_shift() have to be guarded by folio_test_contig() (which will > be fine). The bigger problem is the radix tree. It really only works > for power-of-two sized objects (and honestly, it's not even all that > great for things which aren't a power of 64 in size). See appendix > for more details. Honestly I think this framing the wrong problem. Folios are a way to manage memory which should be about how to manage memory, not about offloading awkward file systems tasks to performance sensitive core code. Right now the proper answer to supporting reflinks on RT devices with non-power of two extent sizes is don't do it, which is pretty easy given that XFS doesn't even support reflink on the RT device at all yet. And if someone has a strong enough use case for eflinks on a weird extent size RT device they'll find way to support it, preferably without making a mess out of the core Linux memory management. Because even if we did support non-power of two folios sizes we'd still need to gurantee XFS would always be able to allocate one for that case, which just sounds like a trainwreck waiting to happen.