On Thu, Oct 28, 2021 at 3:08 PM Drew DeVault wrote: > > 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. > > include/uapi/linux/resource.h | 13 ++++++++++--- > 1 file changed, 10 insertions(+), 3 deletions(-) Forgot to add Signed-off-by tag from the author? -- Ammar Faizi
