Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp1892256rwb; Fri, 2 Dec 2022 02:35:58 -0800 (PST) X-Google-Smtp-Source: AA0mqf4Q0AIBgCNC2iM40HVyQzDVOmPHYT1PvLYy+B4KVC3vtfogtsRlMmd/k3H9IiPno1jd0u3g X-Received: by 2002:a63:ce58:0:b0:473:e2bb:7fc0 with SMTP id r24-20020a63ce58000000b00473e2bb7fc0mr45316989pgi.604.1669977358495; Fri, 02 Dec 2022 02:35:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669977358; cv=none; d=google.com; s=arc-20160816; b=NmtEui6PpahNXANMVP51caAIZK6gLIHJUSxAxfONaZg8e4JTWPIPJQ8hAJcWWc27+j UuSUAkLVDkJYiAvvDjOlib3/AIpiupHQHw5BeJJeotp8DEWB+DMI8nCMmPovyjuhvawk xRjQdllS9/571IDAas1NhzDnQ5Jh9URS1p53grjZQjNIumvnEwqQVvu/BV3iwyBFZnCO 491LV3ezEDmAaXn5P0v5htH80GZOU9qj2UyqL06GVGt2bsITu0HmkYEIHu7z9Lt8eEAW PxATn/MRlsILfLH2O+pGyn8nYIrvHCN7TKgfqbnSgd+xnlVd775InDyBYOtt7vf7nQB9 grQA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=Y9ZqNSTAAKpWCTRDltbyh9yaj6hQDR0ta/KGZMliVz4=; b=Wn/ToWovkKBoPV9i4l3UWLgixEc7JVwbG79iV9NMY6snJUawL+zufTPcuNMRhhQHap qjmLZIY3Xgc8yJ8EHzYoYHt8oBsrJJzQFxr32u/dbzO8fyrJuf3CMRY2pqKJy5NUdfhj JWJI6oymJQeLWAfmSZjFXX1s4v9ec4gkPAdajy36Wv8gGREWsUJQ5S4w4dg5G6mFKPXv X+lD1pMlngb7SYdy0JFzBnC+iwCJbM8xHmYfEE8GQgq4PqN9Dkjh2hLcVD3/olF5QuRR VBCEDt0iGrUYVfZEXYP1PE45ecuShMvcl2y9QYlO28m2V9Y7+x4UupO60UnXLYGHuply Zp3A== ARC-Authentication-Results: i=1; mx.google.com; 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 i11-20020a1709026acb00b0018699a9ea71si6540714plt.18.2022.12.02.02.35.43; Fri, 02 Dec 2022 02:35:58 -0800 (PST) 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; 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 S233172AbiLBKWw (ORCPT + 99 others); Fri, 2 Dec 2022 05:22:52 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35250 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233186AbiLBKWv (ORCPT ); Fri, 2 Dec 2022 05:22:51 -0500 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A0B1125C6A; Fri, 2 Dec 2022 02:22:50 -0800 (PST) Received: by verein.lst.de (Postfix, from userid 2407) id D937167373; Fri, 2 Dec 2022 11:22:45 +0100 (CET) Date: Fri, 2 Dec 2022 11:22:45 +0100 From: Christoph Hellwig To: "Ritesh Harjani (IBM)" Cc: Christoph Hellwig , Namjae Jeon , Sungjong Seo , Jan Kara , OGAWA Hirofumi , Mikulas Patocka , Dave Kleikamp , Bob Copeland , linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, jfs-discussion@lists.sourceforge.net, linux-karma-devel@lists.sourceforge.net, linux-mm@kvack.org Subject: Re: start removing writepage instances Message-ID: <20221202102245.GA17715@lst.de> References: <20221113162902.883850-1-hch@lst.de> <20221116183900.yzpcymelnnwppoh7@riteshh-domain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221116183900.yzpcymelnnwppoh7@riteshh-domain> User-Agent: Mutt/1.5.17 (2007-11-01) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,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 Thu, Nov 17, 2022 at 12:09:00AM +0530, Ritesh Harjani (IBM) wrote: > reclaim. Now IIUC from previous discussions [1][2][3], reclaims happens from > the tail end of the LRU list which could do an I/O of a single page while > an ongoing writeback was in progress of multiple pages. This disrupts the I/O > pattern to become more random in nature, compared to, if we would have let > writeback/flusher do it's job of writing back dirty pages. Yes. > Also many filesystems behave very differently within their ->writepage calls, > e.g. ext4 doesn't actually write in ->writepage for DELAYED blocks. I don't think it's many file systems. As far as I can tell only ext4 actually is significantly different. > 2. Now the other place from where ->writepage can be called from is, writeout() > function, which is a fallback function for migration (fallback_migrate_folio()). > fallback_migrate_folio() is called from move_to_new_folio() if ->migrate_folio > is not defined for the FS. Also there is generic_writepages and folio_write_one/write_one_page. > Is above a correct understanding? Yes.