On 11/4/21 8:27 AM, Cyril Hrubis wrote: > Hi! >>> This limit has not been updated since 2008, when it was increased to 64 >>> KiB at the request of GnuPG. Until recently, the main use-cases for this >>> feature were (1) preventing sensitive memory from being swapped, as in >>> GnuPG's use-case; and (2) real-time use-cases. In the first case, little >>> memory is called for, and in the second case, the user is generally in a >>> position to increase it if they need more. >>> >>> The introduction of IOURING_REGISTER_BUFFERS adds a third use-case: >>> preparing fixed buffers for high-performance I/O. This use-case will >>> take as much of this memory as it can get, but is still limited to 64 >>> KiB by default, which is very little. This increases the limit to 8 MB, >>> which was chosen fairly arbitrarily as a more generous, but still >>> conservative, default value. >>> --- >>> It is also possible to raise this limit in userspace. This is easily >>> done, for example, in the use-case of a network daemon: systemd, for >>> instance, provides for this via LimitMEMLOCK in the service file; OpenRC >>> via the rc_ulimit variables. However, there is no established userspace >>> facility for configuring this outside of daemons: end-user applications >>> do not presently have access to a convenient means of raising their >>> limits. >>> >>> The buck, as it were, stops with the kernel. It's much easier to address >>> it here than it is to bring it to hundreds of distributions, and it can >>> only realistically be relied upon to be high-enough by end-user software >>> if it is more-or-less ubiquitous. Most distros don't change this >>> particular rlimit from the kernel-supplied default value, so a change >>> here will easily provide that ubiquity. >> >> Agree with raising this limit, it is ridiculously low and we often get >> reports from people that can't even do basic rings with it. Particularly >> when bpf is involved as well, as it also dips into this pool. >> >> On the production side at facebook, we do raise this limit as well. > > We are raising this limit to 2MB for LTP testcases as well, otherwise we > get failures when we run a few bpf tests in quick succession.> > Acked-by: Cyril Hrubis <chrubis@xxxxxxx> Andrew, care to pick this one up for 5.16? -- Jens Axboe
