Received: by 2002:a05:6358:16cd:b0:dc:6189:e246 with SMTP id r13csp983434rwl; Fri, 4 Nov 2022 08:30:27 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4DiK/RJln5cSGKhrBrso+hsjcp+FbVCuz9L/SVkcCmcMr6UsaHyBucRFZYvO9bA6a5bJ1q X-Received: by 2002:a17:902:7101:b0:180:202c:ad77 with SMTP id a1-20020a170902710100b00180202cad77mr37350864pll.47.1667575827382; Fri, 04 Nov 2022 08:30:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1667575827; cv=none; d=google.com; s=arc-20160816; b=PC+PoxpMXbmfZ+VzftBST84coLrpMTs9l6w6C0u0uHMarktsr69HM2hUidznUxhr+6 eJSfJchy2LXSkZe3R9qHWWDH3MsU9mYH/tqANJ5IBAjb6ev/dByTAWf+X4hRCbsUa5s3 e6QXIDNtuXmbPPIItKtqLa0EhtczN9OPCiSAXqIB4GpQJqODAF0PLxQsHQH07X9B+Aty 6snzQ4SvPUSbk7+2rv9u8jg0CobaBdVizcv+p+sk643vXBqK7Oe+TflTBoVyReVns91C jOTfgUTup6zS+2FNB0JnfrAB4N2a9z59UKgu6tKL0W9GEj7ybcZjmMKTXJeh/twGK89b vCFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=NRigLoVbg9iNMuo2V8dujDupHLGv4656kHqtcy7GZD8=; b=cd5A9Ote0qPKFKVq4oCFWolg7/49b8eFiP7VDXIJbHwesv2jD0mA7vR3NHS8DlA/d8 6TgYhkg3yIXOzOi8NwkkAfR0SZGOXuqecGiJB5FspG4AJLPFvw6Boe8Hx4uZjlDqpIpP Q2vXsX9TG9q1viA/APhc/XMdgjX+Oc5lYgA767oOtjTy6ev9ly1dgiDG3DmXj1bu0HSS PaEng1+Rl0PVJpZ0nCfxX4ls5rBfeCZds/GpmITIrtJlCWofS3wUT68Y6PCkhFZQ0Wsn wMiefrKFGLp4MraA3BFgdURePGpD4AOIvQwiwXntKzATjuTq1CsYqIMqKdb4lbw1XlHm IGrA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b="cC/8pOU9"; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id jc12-20020a17090325cc00b00186dcc389a8si4310258plb.329.2022.11.04.08.29.49; Fri, 04 Nov 2022 08:30:27 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b="cC/8pOU9"; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232258AbiKDP12 (ORCPT + 99 others); Fri, 4 Nov 2022 11:27:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38750 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232408AbiKDP1P (ORCPT ); Fri, 4 Nov 2022 11:27:15 -0400 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 65E532716E; Fri, 4 Nov 2022 08:27:13 -0700 (PDT) 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=NRigLoVbg9iNMuo2V8dujDupHLGv4656kHqtcy7GZD8=; b=cC/8pOU9guMXpHbLROmQ2jJkPP fLIJJBoVaFImQSaJFL0EWP8TTGFmm1Fq/sTBJJzHOEsig/P1SI1UBIbnctYsc4kfBpEtbkTVb2mcZ Ox1PTbpiMUHAhUcDFiGqO5ffa8RLcaU4htW4J7D1+QIRrp5YcZ701l+dtCKa0/v+wq867Rzs2qjn5 m+hDXZshw76/eeJ25GEvs/oa2Dpn7Gb7+4FfiG7RrZMv4cn4ae/Eyjl07Dbl+O73y7VDkBQtEk8h0 f9z379l8811dl922VVtAq9pc8KIqwTp7lj2fnWcgj+lzkCFo5nZGbwWtuSpe8hnrjhN+krL6P+YDR WpFHYXzg==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1oqybA-007SeM-OG; Fri, 04 Nov 2022 15:27:12 +0000 Date: Fri, 4 Nov 2022 15:27:12 +0000 From: Matthew Wilcox To: Dave Chinner Cc: "Vishal Moola (Oracle)" , linux-fsdevel@vger.kernel.org, linux-afs@lists.infradead.org, linux-kernel@vger.kernel.org, linux-btrfs@vger.kernel.org, ceph-devel@vger.kernel.org, linux-cifs@vger.kernel.org, linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, cluster-devel@redhat.com, linux-nilfs@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 04/23] page-writeback: Convert write_cache_pages() to use filemap_get_folios_tag() Message-ID: References: <20220901220138.182896-1-vishal.moola@gmail.com> <20220901220138.182896-5-vishal.moola@gmail.com> <20221018210152.GH2703033@dread.disaster.area> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221018210152.GH2703033@dread.disaster.area> X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Wed, Oct 19, 2022 at 08:01:52AM +1100, Dave Chinner wrote: > On Thu, Sep 01, 2022 at 03:01:19PM -0700, Vishal Moola (Oracle) wrote: > > @@ -2313,17 +2313,18 @@ int write_cache_pages(struct address_space *mapping, > > while (!done && (index <= end)) { > > int i; > > > > - nr_pages = pagevec_lookup_range_tag(&pvec, mapping, &index, end, > > - tag); > > - if (nr_pages == 0) > > + nr_folios = filemap_get_folios_tag(mapping, &index, end, > > + tag, &fbatch); > > This can find and return dirty multi-page folios if the filesystem > enables them in the mapping at instantiation time, right? Correct. Just like before the patch. pagevec_lookup_range_tag() has only ever returned head pages, never tail pages. This is probably because shmem (which was our only fs that supported compound pages) never supported writeback, so never looked up pages by tag. > > trace_wbc_writepage(wbc, inode_to_bdi(mapping->host)); > > - error = (*writepage)(page, wbc, data); > > + error = writepage(&folio->page, wbc, data); > > Yet, IIUC, this treats all folios as if they are single page folios. > i.e. it passes the head page of a multi-page folio to a callback > that will treat it as a single PAGE_SIZE page, because that's all > the writepage callbacks are currently expected to be passed... > > So won't this break writeback of dirty multipage folios? No. A filesystem only sets the flag to create multipage folios once its writeback callback handles multipage folios correctly (amongst many other things that have to be fixed and tested). I haven't written down all the things that a filesystem maintainer needs to check at least partly because I don't know how representative XFS/iomap are of all filesystems.