Linux filesystem development
 help / color / mirror / Atom feed
From: Jingbo Xu <jefflexu@linux.alibaba.com>
To: Bernd Schubert <bernd.schubert@fastmail.fm>,
	Joanne Koong <joannelkoong@gmail.com>,
	miklos@szeredi.hu, linux-fsdevel@vger.kernel.org
Cc: josef@toxicpanda.com, sweettea-kernel@dorminy.me, kernel-team@meta.com
Subject: Re: [PATCH v2 RESEND] fuse: Enable dynamic configuration of fuse max pages limit (FUSE_MAX_MAX_PAGES)
Date: Fri, 6 Sep 2024 11:18:03 +0800	[thread overview]
Message-ID: <8fc5fd4f-b466-42b1-af9e-1d9cd63aab62@linux.alibaba.com> (raw)
In-Reply-To: <27b6ad2f-9a43-4938-9f0d-2d11581e8be7@fastmail.fm>



On 9/6/24 5:16 AM, Bernd Schubert wrote:
> Hi Joanne,
> 
> On 9/5/24 19:45, Joanne Koong wrote:
>> Introduce the capability to dynamically configure the fuse max pages
>> limit (formerly #defined as FUSE_MAX_MAX_PAGES) through a sysctl.
>> This enhancement allows system administrators to adjust the value
>> based on system-specific requirements.
>>
>> This removes the previous static limit of 256 max pages, which limits
>> the max write size of a request to 1 MiB (on 4096 pagesize systems).
>> Having the ability to up the max write size beyond 1 MiB allows for the
>> perf improvements detailed in this thread [1].
> 
> the change itself looks good to me, but have you seen this discussion here?
> 
> https://lore.kernel.org/lkml/CAJfpegs10SdtzNXJfj3=vxoAZMhksT5A1u5W5L6nKL-P2UOuLQ@mail.gmail.com/T/
> 
> 
> Miklos is basically worried about page pinning and accounting for that
> for unprivileged user processes. 

Yeah this is the blocking issue here when attempting to increase the max
pages limit.

For background requests, maybe this could be fixed by taking the max
pages limit into account when calculating max_user_bgreq. (currently
max_user_bgreq is calculated "assuming 392 bytes per request")

While for synchronous requests, I'm not sure if this indeed matters.  Or
at least it won't be such severe as the pinned memory is limited by the
number of the user process in this case.

-- 
Thanks,
Jingbo

  parent reply	other threads:[~2024-09-06  3:18 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-05 17:45 [PATCH v2 RESEND] fuse: Enable dynamic configuration of fuse max pages limit (FUSE_MAX_MAX_PAGES) Joanne Koong
2024-09-05 18:53 ` Sweet Tea Dorminy
2024-09-05 21:16 ` Bernd Schubert
2024-09-05 22:32   ` Joanne Koong
2024-09-05 22:46     ` Joanne Koong
2024-09-06  3:37     ` Jingbo Xu
2024-09-06  3:18   ` Jingbo Xu [this message]
2024-09-06 18:37 ` kernel test robot
2024-09-06 20:00 ` kernel test robot
2024-09-06 21:52 ` kernel test robot

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=8fc5fd4f-b466-42b1-af9e-1d9cd63aab62@linux.alibaba.com \
    --to=jefflexu@linux.alibaba.com \
    --cc=bernd.schubert@fastmail.fm \
    --cc=joannelkoong@gmail.com \
    --cc=josef@toxicpanda.com \
    --cc=kernel-team@meta.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=sweettea-kernel@dorminy.me \
    /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