public inbox for linux-nfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Trond Myklebust <trondmy@hammerspace.com>
Cc: "bfoster@redhat.com" <bfoster@redhat.com>,
	"snitzer@kernel.org" <snitzer@kernel.org>,
	"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
	"linux-xfs@vger.kernel.org" <linux-xfs@vger.kernel.org>
Subject: Re: [PATCH v2] xfs: enable WQ_MEM_RECLAIM on m_sync_workqueue
Date: Wed, 3 Jul 2024 09:15:30 +1000	[thread overview]
Message-ID: <ZoSKEvqqy3B4uxm7@dread.disaster.area> (raw)
In-Reply-To: <d1af795e3aa83477f90e4521af7ade3a7aed5d4b.camel@hammerspace.com>

On Tue, Jul 02, 2024 at 02:00:46PM +0000, Trond Myklebust wrote:
> On Tue, 2024-07-02 at 23:04 +1000, Dave Chinner wrote:
> > On Tue, Jul 02, 2024 at 12:33:53PM +0000, Trond Myklebust wrote:
> > > On Mon, 2024-07-01 at 10:13 -0400, Mike Snitzer wrote:
> > > > On Mon, Jul 01, 2024 at 09:46:36AM +1000, Dave Chinner wrote:
> > > > > IMO, the only sane way to ensure this sort of nested "back-end
> > > > > page
> > > > > cleaning submits front-end IO filesystem IO" mechanism works is
> > > > > to
> > > > > do something similar to the loop device. You most definitely
> > > > > don't
> > > > > want to be doing buffered IO (double caching is almost always
> > > > > bad)
> > > > > and you want to be doing async direct IO so that the submission
> > > > > thread is not waiting on completion before the next IO is
> > > > > submitted.
> > > > 
> > > > Yes, follow-on work is for me to revive the directio path for
> > > > localio
> > > > that ultimately wasn't pursued (or properly wired up) because it
> > > > creates DIO alignment requirements on NFS client IO:
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/snitzer/linux.git/commit/?h=nfs-localio-for-6.11-testing&id=f6c9f51fca819a8af595a4eb94811c1f90051eab
> > 
> > I don't follow - this is page cache writeback. All the write IO from
> > the bdi flusher thread should be page aligned, right? So why does DIO
> > alignment matter here?
> > 
> 
> There is no guarantee in NFS that writes from the flusher thread are
> page aligned. If a page/folio is known to be up to date, we will
> usually align writes to the boundaries, but we won't guarantee to do a
> read-modify-write if that's not the case. Specifically, we will not do
> so if the file is open for write-only.

So perhaps if the localio mechanism is enabled, it should behave
like a local filesystem and do the page cache RMW cycle (because it
doesn't involve a network round trip) to make sure all the buffered
IO is page aligned. That means both buffered reads and writes are page
aligned, and both can be done using async direct IO. If the client
is doing aligned direct IO, then we can still do async direct IO to
the underlying file. If it's not aligned, then the localio flusher
thread can just do async buffered IO for those IOs instead.

Let's not reinvent the wheel: we know how to do loopback filesystem
IO very efficiently, and the whole point of localio is to do
loopback filesystem IO very efficiently.

-Dave.
-- 
Dave Chinner
david@fromorbit.com

  reply	other threads:[~2024-07-02 23:15 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-28 16:18 [RFC PATCH] xfs: enable WQ_MEM_RECLAIM on m_sync_workqueue Mike Snitzer
2024-06-30 16:35 ` [PATCH v2] " Mike Snitzer
2024-06-30 23:46   ` Dave Chinner
2024-07-01  4:45     ` Christoph Hellwig
2024-07-02 23:51       ` Dave Chinner
2024-07-03 11:29       ` NeilBrown
2024-07-03 14:15         ` Christoph Hellwig
2024-07-03 23:02           ` Dave Chinner
2024-07-09 23:12           ` NeilBrown
2024-07-11 11:55             ` Dave Chinner
2024-07-01 14:13     ` Mike Snitzer
2024-07-02 12:33       ` Trond Myklebust
2024-07-02 13:04         ` Dave Chinner
2024-07-02 14:00           ` Trond Myklebust
2024-07-02 23:15             ` Dave Chinner [this message]
2024-07-06  0:32             ` NeilBrown
2024-07-06  6:13               ` Christoph Hellwig
2024-07-06  6:37                 ` Christoph Hellwig
2024-07-09 23:39                   ` NeilBrown

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=ZoSKEvqqy3B4uxm7@dread.disaster.area \
    --to=david@fromorbit.com \
    --cc=bfoster@redhat.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=snitzer@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox