On Thu, Sep 5, 2024 at 3:32 PM Joanne Koong <joannelkoong@xxxxxxxxx> 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. > > 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 Just realized my wording of "when we do the copying to the fuse server's buffer" can be interpreted in different ways. By this I mean from when we do the "fuse_pages_alloc()" call in fuse_perform_write() to when we finish fuse_send_write_pages(). > request). > > > Thanks, > Joanne > > > > > Thanks, > > Bernd > > > >
