The patch titled
Subject: Increase default MLOCK_LIMIT to 8 MiB
has been added to the -mm tree. Its filename is
increase-default-mlock_limit-to-8-mib.patch
This patch should soon appear at
https://ozlabs.org/~akpm/mmots/broken-out/increase-default-mlock_limit-to-8-mib.patch
and later at
https://ozlabs.org/~akpm/mmotm/broken-out/increase-default-mlock_limit-to-8-mib.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Drew DeVault <sir@xxxxxxxxx>
Subject: Increase default MLOCK_LIMIT to 8 MiB
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.
Link: https://lkml.kernel.org/r/20211028080813.15966-1-sir@xxxxxxxxx
Signed-off-by: Drew DeVault <sir@xxxxxxxxx>
Acked-by: Jens Axboe <axboe@xxxxxxxxx>
Acked-by: Cyril Hrubis <chrubis@xxxxxxx>
Cc: Pavel Begunkov <asml.silence@xxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---
include/uapi/linux/resource.h | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
--- a/include/uapi/linux/resource.h~increase-default-mlock_limit-to-8-mib
+++ a/include/uapi/linux/resource.h
@@ -66,10 +66,17 @@ struct rlimit64 {
#define _STK_LIM (8*1024*1024)
/*
- * GPG2 wants 64kB of mlocked memory, to make sure pass phrases
- * and other sensitive information are never written to disk.
+ * Limit the amount of locked memory by some sane default:
+ * root can always increase this limit if needed.
+ *
+ * The main use-cases are (1) preventing sensitive memory
+ * from being swapped; (2) real-time operations; (3) via
+ * IOURING_REGISTER_BUFFERS.
+ *
+ * The first two don't need much. The latter will take as
+ * much as it can get. 8MB is a reasonably sane default.
*/
-#define MLOCK_LIMIT ((PAGE_SIZE > 64*1024) ? PAGE_SIZE : 64*1024)
+#define MLOCK_LIMIT ((PAGE_SIZE > 8*1024*1024) ? PAGE_SIZE : 8*1024*1024)
/*
* Due to binary compatibility, the actual resource numbers
_
Patches currently in -mm which might be from sir@xxxxxxxxx are
increase-default-mlock_limit-to-8-mib.patch
