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=-6.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 6E22EC432BE for ; Mon, 30 Aug 2021 18:28:21 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 22B8660C3E for ; Mon, 30 Aug 2021 18:28:21 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 22B8660C3E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 99F296B0074; Mon, 30 Aug 2021 14:28:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 94F116B0075; Mon, 30 Aug 2021 14:28:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 83D1B8D0001; Mon, 30 Aug 2021 14:28:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0235.hostedemail.com [216.40.44.235]) by kanga.kvack.org (Postfix) with ESMTP id 722356B0074 for ; Mon, 30 Aug 2021 14:28:20 -0400 (EDT) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 36B8F26DF9 for ; Mon, 30 Aug 2021 18:28:20 +0000 (UTC) X-FDA: 78532581960.07.7D6D6A3 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf29.hostedemail.com (Postfix) with ESMTP id ED2359000094 for ; Mon, 30 Aug 2021 18:28:19 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 0A7A560E98; Mon, 30 Aug 2021 18:28:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1630348099; bh=q7Sa9oLo1QMLGdTm8gSfsqOzZ6zO/A6Cj0Uzj1ZzG6U=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=WanAlxD7OG2mK5TiNVVN8rRFUR/8IocLCJmB9m6K3n5ns6ZumxwOG7A6H+1KcXwrA uIwsL2zIP0tEroxxX+/F3VK+CO7dH5vEmpSC06kOBrROHF7U0cXZ5TEW6Ss1/lobTI npe4LTbziMxbXhUNyCxaz0mrnUtjQyv3Hf1snKRZMWS2G1RZraLuzFtOFMNWCBReJw n0Gxd60W+DY7P/HdsIbInFN63221O+zbRwFwsOwBaWOsYKJZLm69dw1AKXdoO9o/1/ t6TAubAA+EU4WgzyirdD7R+BTsydKulNNQ36Qi3IZJDKQ4MgRwI8qOjcsKJevS+rFI 4wdKzJCaQxo/Q== Date: Mon, 30 Aug 2021 11:28:18 -0700 From: "Darrick J. Wong" To: Andreas Dilger Cc: Matthew Wilcox , 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: <20210830182818.GA9892@magnolia> References: <1FC3646C-259F-4AA4-B7E0-B13E19EDC595@dilger.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1FC3646C-259F-4AA4-B7E0-B13E19EDC595@dilger.ca> Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=WanAlxD7; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf29.hostedemail.com: domain of djwong@kernel.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=djwong@kernel.org X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: ED2359000094 X-Stat-Signature: 5nucdkngoqmx7ymqxyrn7dcw5aa16f5a X-HE-Tag: 1630348099-716402 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 01:27:29PM -0600, Andreas Dilger wrote: > On Aug 28, 2021, at 1:04 PM, Matthew Wilcox wrote: > > > > The current folio work is focused on permitting the VM to use > > physically contiguous chunks of memory. Both Darrick and Johannes > > have pointed out the advantages of supporting logically-contiguous, > > physically-discontiguous chunks of memory. Johannes wants to be able to > > use order-0 allocations to allocate larger folios, getting the benefit > > of managing the memory in larger chunks without requiring the memory > > allocator to be able to find contiguous chunks. Darrick wants to support > > non-power-of-two block sizes. > > What is the use case for non-power-of-two block sizes? The main question > is whether that use case is important enough to add the complexity and > overhead in order to support it? For copy-on-write to a XFS realtime volume where the allocation extent size (we support bigalloc too! :P) is not a power of two (e.g. you set up a 4 disk raid5 with 64k stripes, now the extent size is 192k). Granted, I don't think folios handling 192k chunks is absolutely *required* for folios; the only hard requirement is that if any page in a 192k extent becomes dirty, the rest have to get written out all the same time, and the cow remap can only happen after the last page finishes writeback. --D > Cheers, Andreas > > > > >