On 9/6/24 6:32 AM, Joanne Koong wrote: > On Thu, Sep 5, 2024 at 2:16 PM Bernd Schubert > <bernd.schubert@xxxxxxxxxxx> 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@xxxxxxxxxxxxxx/T/ >> >> >> Miklos is basically worried about page pinning and accounting for that >> for unprivileged user processes. >> > > Thanks for the link to the previous discussion, Bernd. I'll cc Xu and > Jingbo, who started that thread, to this email. > > I'm curious whether this sysctl approach might mitigate those worries > here since modifying the sysctl value will require admin privileges to > explicitly opt into this. I liked Sweet Tea's comment > > "Perhaps, in analogy to soft and hard limits on pipe size, > FUSE_MAX_MAX_PAGES could be increased and treated as the maximum > possible hard limit for max_write; and the default hard limit could stay > at 1M, thereby allowing folks to opt into the new behavior if they care > about the performance more than the memory?" > > where something like this could let admins choose what aspects they'd > like to optimize for. The upper bound of max_pages limit is indeed increased by the sysadmin, but it can't overwhelms the fact that an unpriviledged fuse server could still configure a max_pages limit up to the bound and thus causing the memory pinning issue. > > My understanding of how bigger write buffers affects pinning is that > each chunk of the write will pin a higher number of contiguous pages > at one time (but overall for the duration of the write request, the > number for total pages that get pinned are the same). My understanding > is that the pages only get pinned when we do the copying to the fuse > server's buffer (and is not pinned while the server is servicing the > request). > I think the "possible memory that an unprivileged user is allowed to pin" by Miklos means the possible memory that an unprivileged (even malicious) fuse server could pin? Hi Miklos, would you mind giving more details on this? -- Thanks, Jingbo
