From: Trond Myklebust <trondmy@hammerspace.com>
To: "hch@lst.de" <hch@lst.de>, "willy@infradead.org" <willy@infradead.org>
Cc: "anna@kernel.org" <anna@kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: support large folios for NFS
Date: Wed, 29 May 2024 13:35:06 +0000 [thread overview]
Message-ID: <bea18efca1a72be056ba6a936b9873e53ae3c6d7.camel@hammerspace.com> (raw)
In-Reply-To: <ZlZHNsejJkJNhKHR@casper.infradead.org>
On Tue, 2024-05-28 at 22:05 +0100, Matthew Wilcox wrote:
> On Mon, May 27, 2024 at 06:36:07PM +0200, Christoph Hellwig wrote:
> > Hi all,
> >
> > this series adds large folio support to NFS, and almost doubles the
> > buffered write throughput from the previous bottleneck of ~2.5GB/s
> > (just like for other file systems).
> >
> > The first patch is an old one from willy that I've updated very
> > slightly.
> > Note that this update now requires the mapping_max_folio_size
> > helper
> > merged into Linus' tree only a few minutes ago.
>
> Kind of surprised this didn't fall over given the bugs I just sent a
> patch for ... misinterpreting the folio indices seems like it should
> have caused a failure in _some_ fstest.
Why wouldn't it work? The code you're replacing isn't assuming that
page cache indices are in units of the folio size. It is just assuming
that folio boundaries are multiples of the folio size.
--
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com
next prev parent reply other threads:[~2024-05-29 13:35 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-27 16:36 Christoph Hellwig
2024-05-27 16:36 ` [PATCH 1/2] filemap: Convert generic_perform_write() to support large folios Christoph Hellwig
2024-05-27 18:17 ` Matthew Wilcox
2024-05-28 8:12 ` Christoph Hellwig
[not found] ` <CGME20240528152340eucas1p17ba2ad78d8ea869ef44cdeedb2601f80@eucas1p1.samsung.com>
2024-05-28 15:23 ` Daniel Gomez
2024-05-28 16:50 ` Matthew Wilcox
2024-05-28 19:01 ` Daniel Gomez
2024-06-11 10:47 ` Shaun Tancheff
2024-06-11 16:13 ` Christoph Hellwig
2024-06-12 1:41 ` Shaun Tancheff
2024-06-12 4:02 ` Christoph Hellwig
2024-05-27 16:36 ` [PATCH 2/2] nfs: add support for " Christoph Hellwig
2024-05-27 19:43 ` support large folios for NFS Sagi Grimberg
2024-05-28 21:05 ` Matthew Wilcox
2024-05-29 5:14 ` Christoph Hellwig
2024-05-29 13:35 ` Trond Myklebust [this message]
2024-05-29 21:59 ` Trond Myklebust
2024-05-31 6:14 ` hch
2024-06-07 5:29 ` hch
2024-06-07 7:57 ` Cedric Blancher
2024-06-07 15:32 ` Trond Myklebust
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=bea18efca1a72be056ba6a936b9873e53ae3c6d7.camel@hammerspace.com \
--to=trondmy@hammerspace.com \
--cc=anna@kernel.org \
--cc=hch@lst.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nfs@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox