Linux filesystem development
 help / color / mirror / Atom feed
From: Jingbo Xu <jefflexu@linux.alibaba.com>
To: Joanne Koong <joannelkoong@gmail.com>,
	miklos@szeredi.hu, linux-fsdevel@vger.kernel.org
Cc: josef@toxicpanda.com, bernd.schubert@fastmail.fm,
	willy@infradead.org, shakeel.butt@linux.dev, jlayton@kernel.org,
	kernel-team@meta.com
Subject: Re: [PATCH v3 00/12] fuse: support large folios
Date: Thu, 23 Jan 2025 09:24:21 +0800	[thread overview]
Message-ID: <ff59b715-efa7-4ede-8f82-313af11c51f2@linux.alibaba.com> (raw)
In-Reply-To: <CAJnrk1a8fP7JQRWNhq7uvM=k=RbKrW+V9bOj1CQo=v4ZoNGQ3w@mail.gmail.com>



On 1/23/25 7:23 AM, Joanne Koong wrote:
> On Fri, Dec 13, 2024 at 2:23 PM Joanne Koong <joannelkoong@gmail.com> wrote:
>>
>> This patchset adds support for folios larger than one page size in FUSE.
>>
>> This patchset is rebased on top of the (unmerged) patchset that removes temp
>> folios in writeback [1]. This patchset was tested by running it through fstests
>> on passthrough_hp.
>>
>> Please note that writes are still effectively one page size. Larger writes can
>> be enabled by setting the order on the fgp flag passed in to __filemap_get_folio()
>> but benchmarks show this significantly degrades performance. More investigation
>> needs to be done into this. As such, buffered writes will be optimized in a
>> future patchset.
>>
>> Benchmarks show roughly a ~45% improvement in read throughput.
>>
>> Benchmark setup:
>>
>> -- Set up server --
>>  ./libfuse/build/example/passthrough_hp --bypass-rw=1 ~/libfuse
>> ~/mounts/fuse/ --nopassthrough
>> (using libfuse patched with https://github.com/libfuse/libfuse/pull/807)
>>
>> -- Run fio --
>>  fio --name=read --ioengine=sync --rw=read --bs=1M --size=1G
>> --numjobs=2 --ramp_time=30 --group_reporting=1
>> --directory=mounts/fuse/
>>
>> Machine 1:
>>     No large folios:     ~4400 MiB/s
>>     Large folios:        ~7100 MiB/s
>>
>> Machine 2:
>>     No large folios:     ~3700 MiB/s
>>     Large folios:        ~6400 MiB/s
>>
>>
>> [1] https://lore.kernel.org/linux-fsdevel/20241122232359.429647-1-joannelkoong@gmail.com/
>>
> 
> A couple of updates on this:
> * I'm going to remove the writeback patch (patch 11/12) in this series
> and resubmit, and leave large folios writeback to be done as a
> separate future patchset. Getting writeback to work with large folios
> has a dependency on [1], which unfortunately does not look like it'll
> be resolved anytime soon. If we cannot remove tmp pages, then we'll
> likely need to use a different data structure than the rb tree to
> account for large folios w/ tmp pages. I believe we can still enable
> large folios overall even without large folios writeback, as even with
> the inode->i_mapping set to a large folio order range, writeback will
> still only operate on 4k folios until fgf_set_order() is explicitly
> set in fuse_write_begin() for the __filemap_get_folio() call.
> 
> * There's a discussion here [2] about perf degradation for writeback
> writes on large folios due to writeback throttling when balancing
> dirty pages. This is due to fuse enabling bdi strictlimit. More
> experimentation will be needed to figure out what a good folio order
> is, and whether it's possible to do something like remove the
> strictlimit for privileged servers.

FYI the sysadmin can already disable strictlimit for FUSE through
/sys/class/bdi/<bdi>/strict_limit knob[*].

[*] https://lore.kernel.org/all/20221119005215.3052436-1-shr@devkernel.io/

-- 
Thanks,
Jingbo

  reply	other threads:[~2025-01-23  1:24 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-13 22:18 [PATCH v3 00/12] fuse: support large folios Joanne Koong
2024-12-13 22:18 ` [PATCH v3 01/12] fuse: support copying " Joanne Koong
2024-12-13 22:18 ` [PATCH v3 02/12] fuse: support large folios for retrieves Joanne Koong
2024-12-13 22:18 ` [PATCH v3 03/12] fuse: refactor fuse_fill_write_pages() Joanne Koong
2024-12-13 22:18 ` [PATCH v3 04/12] fuse: support large folios for writethrough writes Joanne Koong
2024-12-19 18:08   ` Jeff Layton
2024-12-19 20:24     ` Matthew Wilcox
2024-12-13 22:18 ` [PATCH v3 05/12] fuse: support large folios for folio reads Joanne Koong
2024-12-13 22:18 ` [PATCH v3 06/12] fuse: support large folios for symlinks Joanne Koong
2024-12-13 22:18 ` [PATCH v3 07/12] fuse: support large folios for stores Joanne Koong
2024-12-13 22:18 ` [PATCH v3 08/12] fuse: support large folios for queued writes Joanne Koong
2024-12-13 22:18 ` [PATCH v3 09/12] fuse: support large folios for readahead Joanne Koong
2024-12-13 22:18 ` [PATCH v3 10/12] fuse: optimize direct io large folios processing Joanne Koong
2024-12-13 22:18 ` [PATCH v3 11/12] fuse: support large folios for writeback Joanne Koong
2024-12-13 22:18 ` [PATCH v3 12/12] fuse: enable large folios Joanne Koong
2024-12-19 18:12 ` [PATCH v3 00/12] fuse: support " Jeff Layton
2025-01-22 23:23 ` Joanne Koong
2025-01-23  1:24   ` Jingbo Xu [this message]
2025-01-23 18:05     ` Joanne Koong
2025-01-23 18:24   ` Matthew Wilcox
2025-01-23 18:42     ` Joanne Koong

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=ff59b715-efa7-4ede-8f82-313af11c51f2@linux.alibaba.com \
    --to=jefflexu@linux.alibaba.com \
    --cc=bernd.schubert@fastmail.fm \
    --cc=jlayton@kernel.org \
    --cc=joannelkoong@gmail.com \
    --cc=josef@toxicpanda.com \
    --cc=kernel-team@meta.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=shakeel.butt@linux.dev \
    --cc=willy@infradead.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