From: Miklos Szeredi <miklos@szeredi.hu>
To: Michael Stapelberg <michael+lkml@stapelberg.ch>
Cc: Tejun Heo <tj@kernel.org>,
Jack Smith <smith.jack.sidman@gmail.com>,
fuse-devel <fuse-devel@lists.sourceforge.net>,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [fuse-devel] Writing to FUSE via mmap extremely slow (sometimes) on some machines?
Date: Mon, 9 Mar 2020 15:36:47 +0100 [thread overview]
Message-ID: <CAJfpegsWwsmzWb6C61NXKh=TEGsc=TaSSEAsixbBvw_qF4R6YQ@mail.gmail.com> (raw)
In-Reply-To: <CANnVG6n=_PhhpgLo2ByGeJrrAaNOLond3GQJhobge7Ob2hfJrQ@mail.gmail.com>
On Mon, Mar 9, 2020 at 3:32 PM Michael Stapelberg
<michael+lkml@stapelberg.ch> wrote:
>
> Here’s one more thing I noticed: when polling
> /sys/kernel/debug/bdi/0:93/stats, I see that BdiDirtied and BdiWritten
> remain at their original values while the kernel sends FUSE read
> requests, and only goes up when the kernel transitions into sending
> FUSE write requests. Notably, the page dirtying throttling happens in
> the read phase, which is most likely why the write bandwidth is
> (correctly) measured as 0.
>
> Do we have any ideas on why the kernel sends FUSE reads at all?
Memory writes (stores) need the memory page to be up-to-date wrt. the
backing file before proceeding. This means that if the page hasn't
yet been cached by the kernel, it needs to be read first.
Thanks,
Miklos
next prev parent reply other threads:[~2020-03-09 14:37 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-24 13:29 Writing to FUSE via mmap extremely slow (sometimes) on some machines? Michael Stapelberg
[not found] ` <CACQJH27s4HKzPgUkVT+FXWLGqJAAMYEkeKe7cidcesaYdE2Vog@mail.gmail.com>
[not found] ` <CANnVG6=Ghu5r44mTkr0uXx_ZrrWo2N5C_UEfM59110Zx+HApzw@mail.gmail.com>
[not found] ` <CAJfpegvzhfO7hg1sb_ttQF=dmBeg80WVkV8srF3VVYHw9ybV0w@mail.gmail.com>
[not found] ` <CANnVG6kSJJw-+jtjh-ate7CC3CsB2=ugnQpA9ACGFdMex8sftg@mail.gmail.com>
[not found] ` <CAJfpegtkEU9=3cvy8VNr4SnojErYFOTaCzUZLYvMuQMi050bPQ@mail.gmail.com>
2020-03-03 10:34 ` [fuse-devel] " Michael Stapelberg
2020-03-03 13:04 ` Tejun Heo
2020-03-03 14:03 ` Michael Stapelberg
2020-03-03 14:13 ` Tejun Heo
2020-03-03 14:21 ` Michael Stapelberg
2020-03-03 14:25 ` Tejun Heo
[not found] ` <CANnVG6=yf82CcwmdmawmjTP2CskD-WhcvkLnkZs7hs0OG7KcTg@mail.gmail.com>
2020-03-09 14:32 ` Michael Stapelberg
2020-03-09 14:36 ` Miklos Szeredi [this message]
2020-03-09 15:11 ` Michael Stapelberg
2020-03-12 15:45 ` Michael Stapelberg
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='CAJfpegsWwsmzWb6C61NXKh=TEGsc=TaSSEAsixbBvw_qF4R6YQ@mail.gmail.com' \
--to=miklos@szeredi.hu \
--cc=fuse-devel@lists.sourceforge.net \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=michael+lkml@stapelberg.ch \
--cc=smith.jack.sidman@gmail.com \
--cc=tj@kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).