From: Horst Birthelmer <horst@birthelmer.de>
To: Joanne Koong <joannelkoong@gmail.com>
Cc: Horst Birthelmer <horst@birthelmer.com>,
Miklos Szeredi <miklos@szeredi.hu>,
Bernd Schubert <bernd@bsbernd.com>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
Horst Birthelmer <hbirthelmer@ddn.com>
Subject: Re: Re: Re: [PATCH] fuse: when copying a folio delay the mark dirty until the end
Date: Wed, 18 Mar 2026 15:03:13 +0100 [thread overview]
Message-ID: <abqvmS4adTXVxFIW@fedora.fritz.box> (raw)
In-Reply-To: <CAJnrk1bBu5VJYnoZcV3uaS7+uyxK6TK9SLDtF2WpcRNfhUvO6w@mail.gmail.com>
On Mon, Mar 16, 2026 at 03:06:02PM -0700, Joanne Koong wrote:
> On Mon, Mar 16, 2026 at 1:02 PM Horst Birthelmer <horst@birthelmer.de> wrote:
> >
> > >
> > > Hi Horst,
> > >
> > > I think these are two different entities. cs->pg is the page that
> > > corresponds to the userspace buffer / pipe while the (large) folio
> > > corresponds to the pages in the page cache. flush_dcache_folio(folio)
> > > and flush_dcache_page(cs->pg) are not interchangeable (I don't think
> > > it's likely either that the pages backing the userspace buffer/pipe
> > > are large folios).
> > >
> > > Thanks,
> > > Joanne
> >
> > Hi Joanne,
> >
> > I feel a bit embarassed ... but you are completely right.
> > I was interested in solving this case:
> >
> > fuse_uring_args_to_ring() or fuse_uring_args_to_ring_pages()
> > fuse_copy_init(&cs, true, &iter) ← cs->write = TRUE
> > fuse_copy_args(&cs, num_args, args->in_pages, ...)
> > if (args->in_pages)
> > fuse_copy_folios(cs, arg->size, 0)
> > fuse_copy_folio(cs, &ap->folios[i], ...)
> >
> > when we have large folios
>
> No worries, the naming doesn't make the distinction obvious at all.
> For copying out large folios right now, the copy is still page by page
> due to extracting 1 userspace buffer page at a time (eg the
> iov_iter_get_pages2(... PAGE_SIZE, 1, ...) call in fuse_copy_fill()).
> If we pass in a pages array, iov_iter_getpages2 is able to extract
> multiple pages at a time and save extra overhead with the GUP setup /
> irq save+restore / pagetable walk and the extra req->waitq
> locking/unlocking calls, but when I benchmarked it last year I didn't
> see any noticeable performance improvements from doing this. The extra
> complexity didn't seem worth it. For optimized copying, I think in the
> future high-performance servers will mostly just use fuse-over-iouring
> zero-copy.
>
> Thanks,
> Joanne
>
Hi Joanne,
I wonder, would something like this help for large folios?
@@ -856,8 +856,11 @@ void fuse_copy_finish(struct fuse_copy_state *cs)
cs->currbuf = NULL;
} else if (cs->pg) {
if (cs->write) {
+ struct folio *folio = page_folio(cs->pg);
+
flush_dcache_page(cs->pg);
- set_page_dirty_lock(cs->pg);
+ if (!folio_test_dirty(folio))
+ set_page_dirty_lock(cs->pg);
}
put_page(cs->pg);
}
Do you have seen any problems with spin locks being way too costly while
doing writes?
That was actually why I started looking into this.
Thanks,
Horst
next prev parent reply other threads:[~2026-03-18 14:11 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-16 15:16 [PATCH] fuse: when copying a folio delay the mark dirty until the end Horst Birthelmer
2026-03-16 17:29 ` Joanne Koong
2026-03-16 20:02 ` Horst Birthelmer
2026-03-16 22:06 ` Joanne Koong
2026-03-18 14:03 ` Horst Birthelmer [this message]
2026-03-18 21:19 ` Joanne Koong
2026-03-18 21:52 ` Bernd Schubert
2026-03-19 1:32 ` Joanne Koong
2026-03-19 4:27 ` Darrick J. Wong
2026-03-20 17:24 ` Joanne Koong
2026-03-19 8:32 ` Horst Birthelmer
2026-03-20 17:18 ` Joanne Koong
2026-03-26 6:35 ` kernel test robot
2026-03-26 6:35 ` [LTP] " kernel test robot
2026-03-26 15:05 ` Cyril Hrubis
2026-03-26 15:05 ` Cyril Hrubis
2026-03-26 15:44 ` Horst Birthelmer
2026-03-26 15:44 ` Horst Birthelmer
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=abqvmS4adTXVxFIW@fedora.fritz.box \
--to=horst@birthelmer.de \
--cc=bernd@bsbernd.com \
--cc=hbirthelmer@ddn.com \
--cc=horst@birthelmer.com \
--cc=joannelkoong@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
/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.