All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hao Xu <hao.xu@linux.dev>
To: Miklos Szeredi <miklos@szeredi.hu>, Bernd Schubert <bschubert@ddn.com>
Cc: fuse-devel@lists.sourceforge.net, bernd.schubert@fastmail.fm,
	Christoph Hellwig <hch@infradead.org>,
	Hao Xu <howeyxu@tencent.com>, Dharmendra Singh <dsingh@ddn.com>,
	linux-fsdevel@vger.kernel.org
Subject: Re: [fuse-devel] [PATCH 1/2] [RFC for fuse-next ] fuse: DIO writes always use the same code path
Date: Thu, 24 Aug 2023 12:32:08 +0800	[thread overview]
Message-ID: <a4d031fa-c5cb-2fe8-5869-ec8ad35cc4ee@linux.dev> (raw)
In-Reply-To: <CAJfpegv6Q5O435xSrYUMEQAvvkObV6gWws8Ju7C+PrSKwjmSew@mail.gmail.com>


On 8/22/23 17:53, Miklos Szeredi via fuse-devel wrote:
> On Mon, 21 Aug 2023 at 19:48, Bernd Schubert <bschubert@ddn.com> wrote:
>> There were two code paths direct-io writes could
>> take. When daemon/server side did not set FOPEN_DIRECT_IO
>>      fuse_cache_write_iter -> direct_write_fallback
>> and with FOPEN_DIRECT_IO being set
>>      fuse_direct_write_iter
>>
>> Advantage of fuse_direct_write_iter is that it has optimizations
>> for parallel DIO writes - it might only take a shared inode lock,
>> instead of the exclusive lock.
>>
>> With commits b5a2a3a0b776/80e4f25262f9 the fuse_direct_write_iter
>> path also handles concurrent page IO (dirty flush and page release),
>> just the condition on fc->direct_io_relax had to be removed.
>>
>> Performance wise this basically gives the same improvements as
>> commit 153524053bbb, just O_DIRECT is sufficient, without the need
>> that server side sets FOPEN_DIRECT_IO
>> (it has to set FOPEN_PARALLEL_DIRECT_WRITES), though.
> Consolidating the various direct IO paths would be really nice.
>
> Problem is that fuse_direct_write_iter() lacks some code from
> generic_file_direct_write() and also completely lacks


I see, seems the page invalidation post direct write is needed

as well.


> direct_write_fallback().   So more thought needs to go into this.
>
> Thanks,
> Miklos
>
>

  parent reply	other threads:[~2023-08-24  4:33 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-21 17:47 [PATCH RFC -next 0/2] fuse: Parallel DIO writes with O_DIRECT Bernd Schubert
2023-08-21 17:47 ` [PATCH 1/2] [RFC for fuse-next ] fuse: DIO writes always use the same code path Bernd Schubert
2023-08-22  9:53   ` Miklos Szeredi
2023-08-22 18:46     ` Bernd Schubert
2023-08-23  6:10       ` Miklos Szeredi
2023-08-24  4:32     ` Hao Xu [this message]
2023-08-24  9:43       ` [fuse-devel] " Bernd Schubert
2023-08-24  9:51         ` Bernd Schubert
2023-08-21 17:47 ` [PATCH 2/2] libfs: Remove export of direct_write_fallback Bernd Schubert

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=a4d031fa-c5cb-2fe8-5869-ec8ad35cc4ee@linux.dev \
    --to=hao.xu@linux.dev \
    --cc=bernd.schubert@fastmail.fm \
    --cc=bschubert@ddn.com \
    --cc=dsingh@ddn.com \
    --cc=fuse-devel@lists.sourceforge.net \
    --cc=hch@infradead.org \
    --cc=howeyxu@tencent.com \
    --cc=linux-fsdevel@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.