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.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,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 1C158C432BE for ; Mon, 30 Aug 2021 18:43:35 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id AEA8660F42 for ; Mon, 30 Aug 2021 18:43:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org AEA8660F42 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 373E06B0074; Mon, 30 Aug 2021 14:43:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 322A36B0075; Mon, 30 Aug 2021 14:43:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 211808D0001; Mon, 30 Aug 2021 14:43:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0239.hostedemail.com [216.40.44.239]) by kanga.kvack.org (Postfix) with ESMTP id 11A726B0074 for ; Mon, 30 Aug 2021 14:43:34 -0400 (EDT) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id C88C98249980 for ; Mon, 30 Aug 2021 18:43:33 +0000 (UTC) X-FDA: 78532620306.08.E989AF9 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf24.hostedemail.com (Postfix) with ESMTP id 210D6B00009F for ; Mon, 30 Aug 2021 18:43:33 +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=HTdApohf3fKpGokZqXcDVUqyTvtY54Ltdsz34HGavd8=; b=EgOq2CKpqZ4hVB4ORDcVotdj4v zW4VqF6Rb++MLTTFWBAxYBeNKBVU5n2MdiA5mHBNqs66FDAmW/3GPrErUtrgQVMyo5IRi1fZCF1CZ FjwIWQfKdC4oIidVjoFGMcDF8SqZtRVzBA3I6xfp5wnqyhgSvG9UP/Z02RZY0S1S0Da2GbO6uA54u oDaq1vxhmOMbMBmrtN0dwuKQGiorsEgZcyqgaf+MThFtd5OvK/+jOV0qb6cdU0i2P4p5lyn6KQUBj 5MctOwRLxlqT8XSNkGfHuEiczwYsh4HIRkdXix4Rc5BJN/xJIFywVvGVaz0+Jh5fHKALziiRfUJ7r gKQh/m2g==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1mKmFJ-000RIR-F2; Mon, 30 Aug 2021 18:43:07 +0000 Date: Mon, 30 Aug 2021 19:43:01 +0100 From: Matthew Wilcox To: "Darrick J. Wong" Cc: Andreas Dilger , 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: <1FC3646C-259F-4AA4-B7E0-B13E19EDC595@dilger.ca> <20210830182818.GA9892@magnolia> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210830182818.GA9892@magnolia> Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=EgOq2CKp; spf=none (imf24.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none X-Stat-Signature: mss69nhj63w715jnzgemr4kkp3t48xuy X-Rspamd-Queue-Id: 210D6B00009F X-Rspamd-Server: rspam04 X-HE-Tag: 1630349013-653989 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 Mon, Aug 30, 2021 at 11:28:18AM -0700, Darrick J. Wong wrote: > 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. I /think/ "all pages get written out at the same time" is basically the same thing as "support a non-power-of-two block size". If we only have page A in the cache at the time it's going to be written back, we have to read in pages B and C in order to calculate the parity P. That will annoy writeback-because-we're-low-on-memory; I know we allow a certain amount of allocation to happen in the writeback path, but requiring 128kB to be allocated is a bit much. So we have to allow page A being dirty to pin pages B and C in the cache. I suppose that's possible; we could make (clean) pages B and C follow page A on the LRU, so they're going to still be in RAM at the time that page A is written back. I don't fully understand how the LRU works, but I assume it'd be a nightmare to ensure that A, B and C all move around the system in the same way. Much easier to ensure that ABC stay linked together and all get written back at once.