All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Jaegeuk Kim <jaegeuk@kernel.org>
Cc: Christoph Hellwig <hch@infradead.org>,
	Bart Van Assche <bvanassche@acm.org>,
	Theodore Tso <tytso@mit.edu>,
	linux-api@vger.kernel.org, linux-kernel@vger.kernel.org,
	Matthew Wilcox <willy@infradead.org>,
	linux-f2fs-devel@lists.sourceforge.net, linux-mm@kvack.org,
	Akilesh Kailash <akailash@google.com>,
	linux-fsdevel@vger.kernel.org,
	Christian Brauner <christian@brauner.io>
Subject: Re: [f2fs-dev] [PATCH v2] f2fs: another way to set large folio by remembering inode number
Date: Thu, 28 May 2026 22:36:39 -0700	[thread overview]
Message-ID: <ahkl52N3RDcusCNd@infradead.org> (raw)
In-Reply-To: <ahcU5xbVy7xjps02@google.com>

On Wed, May 27, 2026 at 03:59:35PM +0000, Jaegeuk Kim wrote:
> F2FS merges bios before submit_bio, regardless of small or large folios,
> since the block addresses are consecutive. So, I think IO subsystem was
> working in full speed.

As does every other remotely modern file system.  But that merging is
surprisingly expensive, which is why using folios gets really major
performance improvements.

For one doing these checks to merge touch quite a few cache lines.
Second, devices are often a lot more efficient if they see fewer SGL
entries.  I.e. having a 1MB bio a single SGL tends to work better than
having 256 of them.
The same is true in the kernel code itself, both in the submission path
(dma mapping and co), and even more so in the page cache handling
both before submitting and in the completion path.

See Bart's patch about how long the walk of the bio_vecs in the f2fs
completion path can take.  We had similar issues in XFS even in the
workqueue completion path due to lack of rescheduling, and these simply
go away when you do the folio manipulation in larger chunks (LAZY_PREEMPT
would avoid the need to explicit rescheduling these days, but that just
papers over the symptoms in this case).


WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@infradead.org>
To: Jaegeuk Kim <jaegeuk@kernel.org>
Cc: Theodore Tso <tytso@mit.edu>,
	Bart Van Assche <bvanassche@acm.org>,
	linux-api@vger.kernel.org, linux-kernel@vger.kernel.org,
	Matthew Wilcox <willy@infradead.org>,
	linux-f2fs-devel@lists.sourceforge.net,
	Christoph Hellwig <hch@infradead.org>,
	linux-mm@kvack.org, linux-fsdevel@vger.kernel.org,
	Akilesh Kailash <akailash@google.com>,
	Christian Brauner <christian@brauner.io>
Subject: Re: [f2fs-dev] [PATCH v2] f2fs: another way to set large folio by remembering inode number
Date: Thu, 28 May 2026 22:36:39 -0700	[thread overview]
Message-ID: <ahkl52N3RDcusCNd@infradead.org> (raw)
In-Reply-To: <ahcU5xbVy7xjps02@google.com>

On Wed, May 27, 2026 at 03:59:35PM +0000, Jaegeuk Kim wrote:
> F2FS merges bios before submit_bio, regardless of small or large folios,
> since the block addresses are consecutive. So, I think IO subsystem was
> working in full speed.

As does every other remotely modern file system.  But that merging is
surprisingly expensive, which is why using folios gets really major
performance improvements.

For one doing these checks to merge touch quite a few cache lines.
Second, devices are often a lot more efficient if they see fewer SGL
entries.  I.e. having a 1MB bio a single SGL tends to work better than
having 256 of them.
The same is true in the kernel code itself, both in the submission path
(dma mapping and co), and even more so in the page cache handling
both before submitting and in the completion path.

See Bart's patch about how long the walk of the bio_vecs in the f2fs
completion path can take.  We had similar issues in XFS even in the
workqueue completion path due to lack of rescheduling, and these simply
go away when you do the folio manipulation in larger chunks (LAZY_PREEMPT
would avoid the need to explicit rescheduling these days, but that just
papers over the symptoms in this case).



_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

  reply	other threads:[~2026-05-29  5:36 UTC|newest]

Thread overview: 116+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-09 13:45 [f2fs-dev] [PATCH] f2fs: another way to set large folio by remembering inode number Jaegeuk Kim via Linux-f2fs-devel
2026-04-09 13:45 ` Jaegeuk Kim
2026-04-10  1:16 ` [f2fs-dev] [PATCH v2] " Jaegeuk Kim via Linux-f2fs-devel
2026-04-10  1:16   ` Jaegeuk Kim
2026-04-14  8:02   ` Christoph Hellwig
2026-04-14  8:02     ` [f2fs-dev] " Christoph Hellwig
2026-04-15 16:44     ` Jaegeuk Kim
2026-04-15 16:44       ` [f2fs-dev] " Jaegeuk Kim via Linux-f2fs-devel
2026-04-15 17:15       ` Matthew Wilcox
2026-04-15 17:15         ` [f2fs-dev] " Matthew Wilcox
2026-04-15 22:02         ` Jaegeuk Kim
2026-04-15 22:02           ` [f2fs-dev] " Jaegeuk Kim via Linux-f2fs-devel
2026-04-15 23:49           ` Darrick J. Wong
2026-04-15 23:49             ` [f2fs-dev] " Darrick J. Wong via Linux-f2fs-devel
2026-04-16  1:19             ` Jaegeuk Kim
2026-04-16  1:19               ` [f2fs-dev] " Jaegeuk Kim via Linux-f2fs-devel
2026-05-21  8:51         ` Christoph Hellwig
2026-05-21  8:51           ` [f2fs-dev] " Christoph Hellwig
2026-05-21 15:57           ` Theodore Tso
2026-05-21 15:57             ` [f2fs-dev] " Theodore Tso
2026-05-21 17:42             ` Matthew Wilcox
2026-05-21 17:42               ` [f2fs-dev] " Matthew Wilcox
2026-05-22  3:59               ` Jaegeuk Kim
2026-05-22  3:59                 ` [f2fs-dev] " Jaegeuk Kim via Linux-f2fs-devel
2026-05-22 12:55                 ` Matthew Wilcox
2026-05-22 12:55                   ` [f2fs-dev] " Matthew Wilcox
2026-05-22 14:04                   ` Jaegeuk Kim
2026-05-22 14:04                     ` Jaegeuk Kim via Linux-f2fs-devel
2026-05-25  5:34                     ` Christoph Hellwig
2026-05-25  5:34                       ` Christoph Hellwig
2026-05-26  1:21                       ` Jaegeuk Kim
2026-05-26  1:21                         ` Jaegeuk Kim via Linux-f2fs-devel
2026-05-26  2:31                         ` Matthew Wilcox
2026-05-26  2:31                           ` Matthew Wilcox
2026-05-26  3:47                           ` Jaegeuk Kim
2026-05-26  3:47                             ` Jaegeuk Kim via Linux-f2fs-devel
2026-05-27  6:33                             ` Christoph Hellwig
2026-05-27  6:33                               ` Christoph Hellwig
2026-05-27  6:26                           ` Christoph Hellwig
2026-05-27  6:26                             ` Christoph Hellwig
2026-05-27 15:42                             ` Jaegeuk Kim
2026-05-27 15:42                               ` Jaegeuk Kim via Linux-f2fs-devel
2026-05-25  5:34               ` Christoph Hellwig
2026-05-25  5:34                 ` [f2fs-dev] " Christoph Hellwig
2026-05-22  3:32             ` Jaegeuk Kim
2026-05-22  3:32               ` Jaegeuk Kim via Linux-f2fs-devel
2026-05-22  3:53               ` Eric Biggers
2026-05-22  3:53                 ` Eric Biggers via Linux-f2fs-devel
2026-05-22  4:02                 ` Jaegeuk Kim
2026-05-22  4:02                   ` Jaegeuk Kim via Linux-f2fs-devel
2026-05-22 10:01                 ` Christian Brauner
2026-05-22 10:01                   ` Christian Brauner via Linux-f2fs-devel
2026-05-22 14:11               ` Theodore Tso
2026-05-22 14:11                 ` Theodore Tso
2026-05-22 17:08                 ` Jaegeuk Kim
2026-05-22 17:08                   ` Jaegeuk Kim via Linux-f2fs-devel
2026-05-22 22:41                   ` Theodore Tso
2026-05-22 22:41                     ` Theodore Tso
2026-05-26  1:10                     ` Jaegeuk Kim
2026-05-26  1:10                       ` Jaegeuk Kim via Linux-f2fs-devel
2026-05-26  2:35                       ` Matthew Wilcox
2026-05-26  2:35                         ` Matthew Wilcox
2026-05-26  3:34                         ` Jaegeuk Kim
2026-05-26  3:34                           ` Jaegeuk Kim via Linux-f2fs-devel
2026-05-26  3:35                       ` Randy Dunlap
2026-05-26  3:35                         ` Randy Dunlap
2026-05-26  4:12                         ` Jaegeuk Kim
2026-05-26  4:12                           ` Jaegeuk Kim via Linux-f2fs-devel
2026-05-26 13:42                       ` Theodore Tso
2026-05-26 13:42                         ` Theodore Tso
2026-05-26 16:14                         ` Bart Van Assche
2026-05-26 16:14                           ` Bart Van Assche via Linux-f2fs-devel
2026-05-27  6:28                           ` Christoph Hellwig
2026-05-27  6:28                             ` Christoph Hellwig
2026-05-27 15:59                             ` Jaegeuk Kim
2026-05-27 15:59                               ` Jaegeuk Kim via Linux-f2fs-devel
2026-05-29  5:36                               ` Christoph Hellwig [this message]
2026-05-29  5:36                                 ` Christoph Hellwig
2026-05-31  0:12                                 ` Jaegeuk Kim
2026-05-31  0:12                                   ` Jaegeuk Kim via Linux-f2fs-devel
2026-05-31  5:28                                   ` Barry Song
2026-05-31  5:28                                     ` Barry Song via Linux-f2fs-devel
2026-06-01  1:52                                     ` Jaegeuk Kim
2026-06-01  1:52                                       ` Jaegeuk Kim via Linux-f2fs-devel
2026-05-26 21:52                         ` Jaegeuk Kim
2026-05-26 21:52                           ` Jaegeuk Kim via Linux-f2fs-devel
2026-05-27  1:21                           ` Theodore Tso
2026-05-27  1:21                             ` Theodore Tso
2026-05-27  2:43                             ` Jaegeuk Kim
2026-05-27  2:43                               ` Jaegeuk Kim via Linux-f2fs-devel
2026-05-27  3:30                               ` Matthew Wilcox
2026-05-27  3:30                                 ` Matthew Wilcox
2026-05-27 15:39                                 ` Jaegeuk Kim
2026-05-27 15:39                                   ` Jaegeuk Kim via Linux-f2fs-devel
2026-05-27  6:31                             ` Christoph Hellwig
2026-05-27  6:31                               ` Christoph Hellwig
2026-05-27  1:15                         ` Bart Van Assche via Linux-f2fs-devel
2026-05-27  1:15                           ` Bart Van Assche
2026-05-28 19:36                       ` Matthew Wilcox
2026-05-28 19:36                         ` Matthew Wilcox
2026-05-31  0:35                         ` Jaegeuk Kim
2026-05-31  0:35                           ` Jaegeuk Kim via Linux-f2fs-devel
2026-05-25  5:37               ` Christoph Hellwig
2026-05-25  5:37                 ` Christoph Hellwig
2026-05-22  9:59             ` Christian Brauner
2026-05-22  9:59               ` [f2fs-dev] " Christian Brauner via Linux-f2fs-devel
2026-04-15 16:41   ` Jaegeuk Kim
2026-04-15 16:41     ` [f2fs-dev] " Jaegeuk Kim via Linux-f2fs-devel
2026-04-17  0:58   ` Chao Yu via Linux-f2fs-devel
2026-04-17  0:58     ` Chao Yu
2026-04-17 16:54     ` Jaegeuk Kim via Linux-f2fs-devel
2026-04-17 16:54       ` Jaegeuk Kim
2026-04-18  1:08       ` Chao Yu via Linux-f2fs-devel
2026-04-18  1:08         ` Chao Yu
2026-04-18  1:11   ` Chao Yu via Linux-f2fs-devel
2026-04-18  1:11     ` Chao Yu

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=ahkl52N3RDcusCNd@infradead.org \
    --to=hch@infradead.org \
    --cc=akailash@google.com \
    --cc=bvanassche@acm.org \
    --cc=christian@brauner.io \
    --cc=jaegeuk@kernel.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=tytso@mit.edu \
    --cc=willy@infradead.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.