mm-commits.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: akpm@linux-foundation.org, ammarfaizi2@gnuweeb.org,
	andrew@donacou.ch, asml.silence@gmail.com, axboe@kernel.dk,
	chrubis@suse.cz, david@redhat.com, hannes@cmpxchg.org,
	jgg@ziepe.ca, linux-mm@kvack.org, mm-commits@vger.kernel.org,
	sir@cmpwn.com, torvalds@linux-foundation.org
Subject: [patch 01/21] Increase default MLOCK_LIMIT to 8 MiB
Date: Fri, 10 Dec 2021 14:46:09 -0800	[thread overview]
Message-ID: <20211210224609.9QkKor7T0%akpm@linux-foundation.org> (raw)
In-Reply-To: <20211210144539.663efee2c80d8450e6180230@linux-foundation.org>

From: Drew DeVault <sir@cmpwn.com>
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@cmpwn.com
Signed-off-by: Drew DeVault <sir@cmpwn.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Acked-by: Cyril Hrubis <chrubis@suse.cz>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: Pavel Begunkov <asml.silence@gmail.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Andrew Dona-Couch <andrew@donacou.ch>
Cc: Ammar Faizi <ammarfaizi2@gnuweeb.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 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
_

  reply	other threads:[~2021-12-10 22:46 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-10 22:45 incoming Andrew Morton
2021-12-10 22:46 ` Andrew Morton [this message]
2021-12-11  1:08   ` [patch 01/21] Increase default MLOCK_LIMIT to 8 MiB Linus Torvalds
2021-12-10 22:46 ` [patch 02/21] MAINTAINERS: update kdump maintainers Andrew Morton
2021-12-10 22:46 ` [patch 03/21] mailmap: update email address for Guo Ren Andrew Morton
2021-12-10 22:46 ` [patch 04/21] filemap: remove PageHWPoison check from next_uptodate_page() Andrew Morton
2021-12-10 22:46 ` [patch 05/21] timers: implement usleep_idle_range() Andrew Morton
2021-12-10 22:46 ` [patch 06/21] mm/damon/core: fix fake load reports due to uninterruptible sleeps Andrew Morton
2021-12-10 22:46 ` [patch 07/21] mm/damon/core: use better timer mechanisms selection threshold Andrew Morton
2021-12-10 22:46 ` [patch 08/21] mm/damon/dbgfs: remove an unnecessary error message Andrew Morton
2021-12-10 22:46 ` [patch 09/21] mm/damon/core: remove unnecessary error messages Andrew Morton
2021-12-10 22:46 ` [patch 10/21] mm/damon/vaddr: remove an unnecessary warning message Andrew Morton
2021-12-10 22:46 ` [patch 11/21] mm/damon/vaddr-test: split a test function having >1024 bytes frame size Andrew Morton
2021-12-10 22:46 ` [patch 12/21] mm/damon/vaddr-test: remove unnecessary variables Andrew Morton
2021-12-10 22:46 ` [patch 13/21] selftests/damon: skip test if DAMON is running Andrew Morton
2021-12-10 22:46 ` [patch 14/21] selftests/damon: test DAMON enabling with empty target_ids case Andrew Morton
2021-12-10 22:46 ` [patch 15/21] selftests/damon: test wrong DAMOS condition ranges input Andrew Morton
2021-12-10 22:46 ` [patch 16/21] selftests/damon: test debugfs file reads/writes with huge count Andrew Morton
2021-12-10 22:46 ` [patch 17/21] selftests/damon: split test cases Andrew Morton
2021-12-10 22:47 ` [patch 18/21] mm/slub: fix endianness bug for alloc/free_traces attributes Andrew Morton
2021-12-10 22:47 ` [patch 19/21] mm/memcg: relocate mod_objcg_mlstate(), get_obj_stock() and put_obj_stock() Andrew Morton
2021-12-10 22:47 ` [patch 20/21] hugetlbfs: fix issue of preallocation of gigantic pages can't work Andrew Morton
2021-12-10 22:47 ` [patch 21/21] mm: bdi: initialize bdi_min_ratio when bdi is unregistered Andrew Morton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20211210224609.9QkKor7T0%akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=ammarfaizi2@gnuweeb.org \
    --cc=andrew@donacou.ch \
    --cc=asml.silence@gmail.com \
    --cc=axboe@kernel.dk \
    --cc=chrubis@suse.cz \
    --cc=david@redhat.com \
    --cc=hannes@cmpxchg.org \
    --cc=jgg@ziepe.ca \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mm-commits@vger.kernel.org \
    --cc=sir@cmpwn.com \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).