From: Miklos Szeredi <miklos@szeredi.hu>
To: 刘硕然 <liushuoran@jd.com>
Cc: "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
刘海锋 <bjliuhaifeng@jd.com>, 郭卫龙 <guoweilong@jd.com>
Subject: Re: FUSE: write operations trigger balance_dirty_pages when using writeback cache
Date: Thu, 9 Aug 2018 14:25:47 +0200 [thread overview]
Message-ID: <CAJfpegt4ymM8Zuto8vDX4djP5S-t3DMaaKn0ntwCsG1JaBpExg@mail.gmail.com> (raw)
In-Reply-To: <EA52CBCF76D5E04D95BED55B83577BE7A677C0@MBX50.360buyAD.local>
On Thu, Aug 9, 2018 at 2:08 PM, 刘硕然 <liushuoran@jd.com> wrote:
> Thanks for the advice. I tried removing BDI_CAP_STRICTLIMIT, and it works. There is no balance_dirty_pages() triggered, and the performance improves a lot.
>
> Tested by libfuse passthrough_ll example and fio:
> ./passthrough_ll -o writeback /mnt/fuse/
> fio --name=test --ioengine=psync --directory=/mnt/fuse/home/test --bs=4k --direct=0 --size=64M --rw=write --fallocate=0 --numjobs=1
>
> performance with BDI_CAP_STRICTLIMIT:
> WRITE: bw=158MiB/s (165MB/s), 158MiB/s-158MiB/s (165MB/s-165MB/s), io=64.0MiB (67.1MB), run=406-406msec
>
> Performance without BDI_CAP_STRICTLIMIT:
> WRITE: bw=1561MiB/s (1637MB/s), 1561MiB/s-1561MiB/s (1637MB/s-1637MB/s), io=64.0MiB (67.1MB), run=41-41msec
>
> However, I wonder if there are some side-effects to remove it? Since it seems that the original purpose of this feature is to prevent FUSE from consuming too much memory.
Yes. So if BDI_CAP_STRICTLIMIT is causing a serious performance
bottleneck, then we need to think about solving this without losing
the benefits. Simply removing it is definitely not a proper solution.
Thanks,
Miklos
prev parent reply other threads:[~2018-08-09 12:25 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-09 12:08 刘硕然
2018-08-09 12:25 ` Miklos Szeredi [this message]
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=CAJfpegt4ymM8Zuto8vDX4djP5S-t3DMaaKn0ntwCsG1JaBpExg@mail.gmail.com \
--to=miklos@szeredi.hu \
--cc=bjliuhaifeng@jd.com \
--cc=guoweilong@jd.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=liushuoran@jd.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