From: Matthew Wilcox <willy@infradead.org>
To: Trond Myklebust <trondmy@hammerspace.com>
Cc: "linux-cachefs@redhat.com" <linux-cachefs@redhat.com>,
"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
"daire.byrne@gmail.com" <daire.byrne@gmail.com>,
"anna.schumaker@netapp.com" <anna.schumaker@netapp.com>,
"benmaynard@google.com" <benmaynard@google.com>,
"dhowells@redhat.com" <dhowells@redhat.com>,
"dwysocha@redhat.com" <dwysocha@redhat.com>
Subject: Re: [RFC PATCH 2/3] NFS: Add support for netfs in struct nfs_inode and Kconfig
Date: Thu, 25 Aug 2022 18:53:15 +0100 [thread overview]
Message-ID: <Ywe3C/EvKFYEwKPy@casper.infradead.org> (raw)
In-Reply-To: <b4cbbdef254e9e0e6feb41455d809aaf0c5abfdb.camel@hammerspace.com>
On Thu, Aug 25, 2022 at 03:32:25PM +0000, Trond Myklebust wrote:
> I'm not talking about the transition of dirty->clean. We already deal
> with that. I'm talking about supporting large folios on read-mainly
> workloads.
>
> NFS can happily support 1MB sized folios, or even larger than that if
> there is a compelling reason to do so.
>
> However, having to read in the entire folio contents if the user is
> just asking for a few bytes on a database-style random read workload
> can quickly get onerous.
Ah, we don't do that. If the user is only asking for a few bytes and
there's no indication that it's part of a streaming read, we allocate &
fill a single page, just as before. We adapt to the user's workload
and only allocate multi-page folios when there's evidence that it'll
be useful to do so.
next prev parent reply other threads:[~2022-08-25 17:53 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-24 9:34 [RFC PATCH 0/3] Convert NFS to the new netfs API Dave Wysochanski
2022-08-24 9:34 ` [RFC PATCH 1/3] NFS: Rename readpage_async_filler to nfs_pageio_add_page Dave Wysochanski
2022-08-24 9:35 ` [RFC PATCH 2/3] NFS: Add support for netfs in struct nfs_inode and Kconfig Dave Wysochanski
2022-08-24 12:42 ` Trond Myklebust
2022-08-24 13:00 ` David Wysochanski
2022-08-24 13:05 ` Trond Myklebust
2022-08-24 14:12 ` David Howells
2022-08-24 16:27 ` Trond Myklebust
2022-08-24 16:53 ` Matthew Wilcox
2022-08-24 17:43 ` Trond Myklebust
2022-08-25 15:01 ` Matthew Wilcox
2022-08-25 15:30 ` David Howells
2022-08-25 15:32 ` Trond Myklebust
2022-08-25 17:53 ` Matthew Wilcox [this message]
2022-08-25 15:20 ` David Howells
2022-08-24 9:35 ` [RFC PATCH 3/3] NFS: Convert nfs_read_folio and nfs_readahead to netfs APIs Dave Wysochanski
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=Ywe3C/EvKFYEwKPy@casper.infradead.org \
--to=willy@infradead.org \
--cc=anna.schumaker@netapp.com \
--cc=benmaynard@google.com \
--cc=daire.byrne@gmail.com \
--cc=dhowells@redhat.com \
--cc=dwysocha@redhat.com \
--cc=linux-cachefs@redhat.com \
--cc=linux-nfs@vger.kernel.org \
--cc=trondmy@hammerspace.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 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.