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
Date: Thu, 17 Nov 2022 00:09:00 +0530 [thread overview]
Message-ID: <20221116183900.yzpcymelnnwppoh7@riteshh-domain> (raw)
In-Reply-To: <20221113162902.883850-1-hch@lst.de>
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(-)
next prev parent reply other threads:[~2022-11-16 18:39 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-13 16:28 Christoph Hellwig
2022-11-13 16:28 ` [PATCH 1/9] extfat: remove ->writepage Christoph Hellwig
2022-11-14 11:07 ` Namjae Jeon
2022-11-13 16:28 ` [PATCH 2/9] ext2: " Christoph Hellwig
2022-11-14 10:49 ` Jan Kara
2022-11-16 16:14 ` Christoph Hellwig
2022-11-16 18:20 ` [PATCH 2/9] ext2: remove ->writepageo Jan Kara
2022-11-17 6:31 ` Christoph Hellwig
2022-11-21 10:07 ` Jan Kara
2022-11-13 16:28 ` [PATCH 3/9] fat: remove ->writepage Christoph Hellwig
2022-11-13 16:28 ` [PATCH 4/9] hfs: " Christoph Hellwig
2023-12-14 19:01 ` Matthew Wilcox
2023-12-15 4:59 ` Christoph Hellwig
2022-11-13 16:28 ` [PATCH 5/9] hfsplus: " Christoph Hellwig
2022-11-13 16:28 ` [PATCH 6/9] hpfs: " Christoph Hellwig
2022-11-13 16:29 ` [PATCH 7/9] jfs: " Christoph Hellwig
2022-11-14 14:29 ` Dave Kleikamp
2022-11-13 16:29 ` [PATCH 8/9] omfs: " Christoph Hellwig
2022-11-15 2:34 ` Bob Copeland
2022-11-13 16:29 ` [PATCH 9/9] udf: " Christoph Hellwig
2022-11-14 10:52 ` Jan Kara
2022-11-14 20:29 ` start removing writepage instances Johannes Weiner
2022-11-16 18:39 ` Ritesh Harjani (IBM) [this message]
2022-12-02 10:22 ` Christoph Hellwig
2022-11-17 21:39 ` David Howells
2022-11-17 21:41 ` David Howells
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20221116183900.yzpcymelnnwppoh7@riteshh-domain \
--to=ritesh.list@gmail.com \
--cc=hch@lst.de \
--cc=hirofumi@mail.parknet.co.jp \
--cc=jack@suse.com \
--cc=jfs-discussion@lists.sourceforge.net \
--cc=linkinjeon@kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-karma-devel@lists.sourceforge.net \
--cc=linux-mm@kvack.org \
--cc=me@bobcopeland.com \
--cc=mikulas@artax.karlin.mff.cuni.cz \
--cc=shaggy@kernel.org \
--cc=sj1557.seo@samsung.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox