Re: [HELP] FUSE writeback performance bottleneck
From: Joanne Koong
Date: Thu Aug 22 2024 - 13:01:46 EST
On Tue, Jun 4, 2024 at 3:02 AM Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
>
> On Tue, 4 Jun 2024 at 11:32, Bernd Schubert <bernd.schubert@xxxxxxxxxxx> wrote:
>
> > Back to the background for the copy, so it copies pages to avoid
> > blocking on memory reclaim. With that allocation it in fact increases
> > memory pressure even more. Isn't the right solution to mark those pages
> > as not reclaimable and to avoid blocking on it? Which is what the tmp
> > pages do, just not in beautiful way.
>
> Copying to the tmp page is the same as marking the pages as
> non-reclaimable and non-syncable.
>
> Conceptually it would be nice to only copy when there's something
> actually waiting for writeback on the page.
>
> Note: normally the WRITE request would be copied to userspace along
> with the contents of the pages very soon after starting writeback.
> After this the contents of the page no longer matter, and we can just
> clear writeback without doing the copy.
>
> But if the request gets stuck in the input queue before being copied
> to userspace, then deadlock can still happen if the server blocks on
> direct reclaim and won't continue with processing the queue. And
> sync(2) will also block in that case.
Why doesn't it suffice to just check if the page is being reclaimed
and do the tmp page allocation only if it's under reclaim?
>
> So we'd somehow need to handle stuck WRITE requests. I don't see an
> easy way to do this "on demand", when something actually starts
> waiting on PG_writeback. Alternatively the page copy could be done
> after a timeout, which is ugly, but much easier to implement.
>
> Also splice from the fuse dev would need to copy those pages, but that
> shouldn't be a problem, since it's just moving the copy from one place
> to another.
>
> Thanks,
> Miklos