archive mirror
 help / color / mirror / Atom feed
From: 刘硕然 <>
To: Constantine Shulyupin <>
Cc: Miklos Szeredi <>,
	<>, Jonathan Corbet <>,
	"" <>,
	"Amir Goldstein" <>
Subject: 答复: [PATCH v4] fuse: add max_pages option
Date: Wed, 26 Sep 2018 10:39:40 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

商城技术架构部   智能存储部
手机/+86 18201588100

> -----邮件原件-----
> 发件人: Constantine Shulyupin []
> 发送时间: 2018年9月26日 18:07
> 收件人: 刘硕然 <>
> 抄送: Miklos Szeredi <>; open list:FUSE: FILESYSTEM IN
> USERSPACE <>; Jonathan Corbet
> <>;; Amir Goldstein
> <>
> 主题: Re: [PATCH v4] fuse: add max_pages option
> Hi Shuoran,
> On Wed, Sep 26, 2018 at 12:40 PM 刘硕然 <> wrote:
> > I haven't tested the patch yet. But after reviewing the patch, I don't see
> anything related to BDI_CAP_STRICTLIMIT. So would you please explain a
> little bit more? Thanks.
> Bigger size of request reduces total number of requests and reduces
> overhead of per request operations.
> > PS: I did try increasing FUSE_MAX_PAGES_PER_REQ, but it seemed not
> helping in my scenario(writeback cache enabled, 4K writes, total write size is
> not very large).
> To utilize FUSE_MAX_PAGES_PER_REQ in kernel it is must to increase
> KERNEL_BUF_PAGES it libfuse too. I have libfuse patch with configurable
> max_pages.
> But 4K writes will not benefit from increase of request size, which now is
> 128K and proposed size is 1M.

This is true. So my original purpose of using writeback cache was trying to improve the performance of small writes. Because for big writes, fuse kernel would send requests to libfuse anyway, with or without writeback cache.

The BDI_CAP_STRICTLIMIT issue happens when writeback cache is enabled, since balance_dirty_pages() is triggered in every small writes even if no request is sent to libfuse, which slows things down.

So IMHO, increasing FUSE_MAX_PAGES_PER_REQ would certainly help for big writes, but might not be a solution to BDI_CAP_STRICTLIMIT issue. Please feel free to correct me if I misunderstand anything. Thanks in advance.

> Thanks

  reply	other threads:[~2018-09-26 16:52 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-06 12:37 [PATCH v4] fuse: add max_pages option Constantine Shulyupin
2018-09-26  8:54 ` Constantine Shulyupin
2018-09-26  9:19   ` Miklos Szeredi
2018-09-26  9:39     ` 答复: " 刘硕然
2018-09-26 10:06       ` Constantine Shulyupin
2018-09-26 10:39         ` 刘硕然 [this message]
2018-10-01  9:18           ` 答复: " Miklos Szeredi
2018-10-01  9:16   ` Miklos Szeredi

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \

* 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).