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;
Date:   Thu, 17 Nov 2022 00:09:00 +0530
From:   "Ritesh Harjani (IBM)" <ritesh.list@gmail.com>
To:     Christoph Hellwig <hch@lst.de>
Cc:     Namjae Jeon <linkinjeon@kernel.org>,
        Sungjong Seo <sj1557.seo@samsung.com>,
        Jan Kara <jack@suse.com>,
        OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>,
        Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>,
        Dave Kleikamp <shaggy@kernel.org>,
        Bob Copeland <me@bobcopeland.com>,
        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: <20221116183900.yzpcymelnnwppoh7@riteshh-domain>
References: <20221113162902.883850-1-hch@lst.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20221113162902.883850-1-hch@lst.de>
Precedence: bulk

On 22/11/13 05:28PM, Christoph Hellwig wrote:
> Hi all,
> 
> The VM doesn't need or want ->writepage for writeback and is fine with
> just having ->writepages as long as ->migrate_folio is implemented.

Ok, so here is, (what I think) is the motivation for doing this. 
Please correct me if this is incorrect... 
1. writepage is mainly called from pageout, which happens as part of the memory
   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.

   Also many filesystems behave very differently within their ->writepage calls,
   e.g. ext4 doesn't actually write in ->writepage for DELAYED blocks.

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.

So what you are doing here is removing the ->writepage from address_space
operations of the filesystems which implements ->writepage using
block_write_full_page() (i.e. those who uses buffer_heads). This is done for 
those FS who already have ->migrate_folio() implemented (hence no need of
->writepage).
...Now this is also a step towards reducing the callers from kernel which uses
buffer_heads.

[1]: https://lore.kernel.org/all/1310567487-15367-1-git-send-email-mgorman@suse.de/
[2]: https://lore.kernel.org/all/20181107063127.3902-2-david@fromorbit.com/
[3]: https://lore.kernel.org/all/1271117878-19274-1-git-send-email-david@fromorbit.com/

Is above a correct understanding?

> 
> This series removes all ->writepage instances that use
> block_write_full_page directly and also have a plain mpage_writepages
> based ->writepages.

Ok.


> 
> Diffstat:
>  fs/exfat/inode.c   |    9 ++-------
>  fs/ext2/inode.c    |    6 ------
>  fs/fat/inode.c     |    9 ++-------
>  fs/hfs/inode.c     |    2 +-
>  fs/hfsplus/inode.c |    2 +-
>  fs/hpfs/file.c     |    9 ++-------
>  fs/jfs/inode.c     |    7 +------
>  fs/omfs/file.c     |    7 +------
>  fs/udf/inode.c     |    7 +------
>  9 files changed, 11 insertions(+), 47 deletions(-)