From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it1-f195.google.com ([209.85.166.195]:54662 "EHLO mail-it1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728902AbeJAPzt (ORCPT ); Mon, 1 Oct 2018 11:55:49 -0400 Received: by mail-it1-f195.google.com with SMTP id l191-v6so4718763ita.4 for ; Mon, 01 Oct 2018 02:19:00 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <26b698ef4d96469cae90d62188c9fe02@jd.com> References: <20180906123706.28691-1-const@MakeLinux.com> <26b698ef4d96469cae90d62188c9fe02@jd.com> From: Miklos Szeredi Date: Mon, 1 Oct 2018 11:18:59 +0200 Message-ID: Subject: =?UTF-8?B?UmU6IOetlOWkjTogW1BBVENIIHY0XSBmdXNlOiBhZGQgbWF4X3BhZ2VzIG9wdGlvbg==?= To: =?UTF-8?B?5YiY56GV54S2?= Cc: Constantine Shulyupin , "open list:FUSE: FILESYSTEM IN USERSPACE" , Jonathan Corbet , "mitsuo.hayasaka.hu@hitachi.com" , Amir Goldstein Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Wed, Sep 26, 2018 at 12:39 PM, =E5=88=98=E7=A1=95=E7=84=B6 wrote: > > > =E5=88=98=E7=A1=95=E7=84=B6 > =E5=95=86=E5=9F=8E=E6=8A=80=E6=9C=AF=E6=9E=B6=E6=9E=84=E9=83=A8 =E6=99= =BA=E8=83=BD=E5=AD=98=E5=82=A8=E9=83=A8 > -------------------------------------------------------------------------= ----------------------- > =E6=89=8B=E6=9C=BA=EF=BC=8F+86 18201588100 > =E9=82=AE=E7=AE=B1=EF=BC=8Fliushuoran@jd.com > =E5=9C=B0=E5=9D=80=EF=BC=8F=E5=8C=97=E4=BA=AC=E5=B8=82=E7=BB=8F=E6=B5=8E= =E6=8A=80=E6=9C=AF=E5=BC=80=E5=8F=91=E5=8C=BA=E7=A7=91=E5=88=9B=E5=8D=81=E4= =B8=80=E8=A1=9718=E5=8F=B7=E9=99=A2=E4=BA=AC=E4=B8=9C=E5=A4=A7=E5=8E=A6B=E5= =BA=A716=E5=B1=82 > -------------------------------------------------------------------------= ----------------------- > > > >> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >> =E5=8F=91=E4=BB=B6=E4=BA=BA: Constantine Shulyupin [mailto:const@makelin= ux.com] >> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2018=E5=B9=B49=E6=9C=8826=E6=97=A5= 18:07 >> =E6=94=B6=E4=BB=B6=E4=BA=BA: =E5=88=98=E7=A1=95=E7=84=B6 >> =E6=8A=84=E9=80=81: Miklos Szeredi ; open list:FUSE: = FILESYSTEM IN >> USERSPACE ; Jonathan Corbet >> ; mitsuo.hayasaka.hu@hitachi.com; Amir Goldstein >> >> =E4=B8=BB=E9=A2=98: Re: [PATCH v4] fuse: add max_pages option >> >> Hi Shuoran, >> >> On Wed, Sep 26, 2018 at 12:40 PM =E5=88=98=E7=A1=95=E7=84=B6 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 s= ize 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 ke= rnel would send requests to libfuse anyway, with or without writeback cache= . > > The BDI_CAP_STRICTLIMIT issue happens when writeback cache is enabled, si= nce balance_dirty_pages() is triggered in every small writes even if no req= uest is sent to libfuse, which slows things down. > > So IMHO, increasing FUSE_MAX_PAGES_PER_REQ would certainly help for big w= rites, but might not be a solution to BDI_CAP_STRICTLIMIT issue. Please fee= l free to correct me if I misunderstand anything. Thanks in advance. Makes sense. Can you do a kernel profile to see where most of the time is actually spent in your workload? Thanks, Miklos