From: Cyril Hrubis <[email protected]>
To: Jens Axboe <[email protected]>
Cc: Drew DeVault <[email protected]>,
[email protected], [email protected],
[email protected], Pavel Begunkov <[email protected]>
Subject: Re: [PATCH] Increase default MLOCK_LIMIT to 8 MiB
Date: Thu, 4 Nov 2021 15:27:32 +0100 [thread overview]
Message-ID: <YYPt1PaGtiSLvyKw@rei> (raw)
In-Reply-To: <[email protected]>
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 <[email protected]>
--
Cyril Hrubis
[email protected]
next prev parent reply other threads:[~2021-11-04 14:27 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-28 8:08 [PATCH] Increase default MLOCK_LIMIT to 8 MiB Drew DeVault
2021-10-28 18:22 ` Jens Axboe
2021-11-04 14:27 ` Cyril Hrubis [this message]
2021-11-04 14:44 ` Jens Axboe
2021-11-06 2:33 ` Ammar Faizi
2021-11-06 7:05 ` Drew DeVault
2021-11-06 7:12 ` Ammar Faizi
2021-11-16 4:35 ` Andrew Morton
2021-11-16 6:32 ` Drew DeVault
2021-11-16 19:47 ` Andrew Morton
2021-11-16 19:48 ` Drew DeVault
2021-11-16 21:37 ` Andrew Morton
2021-11-17 8:23 ` Drew DeVault
2021-11-22 17:11 ` David Hildenbrand
2021-11-22 17:55 ` Andrew Dona-Couch
2021-11-22 18:26 ` David Hildenbrand
2021-11-22 19:53 ` Jens Axboe
2021-11-22 20:03 ` Matthew Wilcox
2021-11-22 20:04 ` Jens Axboe
2021-11-22 20:08 ` David Hildenbrand
2021-11-22 20:44 ` Jens Axboe
2021-11-22 21:56 ` David Hildenbrand
2021-11-23 12:02 ` David Hildenbrand
2021-11-23 13:25 ` Jason Gunthorpe
2021-11-23 13:39 ` David Hildenbrand
2021-11-23 14:07 ` Jason Gunthorpe
2021-11-23 14:44 ` David Hildenbrand
2021-11-23 17:00 ` Jason Gunthorpe
2021-11-23 17:04 ` David Hildenbrand
2021-11-23 22:04 ` Vlastimil Babka
2021-11-23 23:59 ` Jason Gunthorpe
2021-11-24 8:57 ` David Hildenbrand
2021-11-24 13:23 ` Jason Gunthorpe
2021-11-24 13:25 ` David Hildenbrand
2021-11-24 13:28 ` Jason Gunthorpe
2021-11-24 13:29 ` David Hildenbrand
2021-11-24 13:48 ` Jason Gunthorpe
2021-11-24 14:14 ` David Hildenbrand
2021-11-24 15:34 ` Jason Gunthorpe
2021-11-24 16:43 ` David Hildenbrand
2021-11-24 18:35 ` Jason Gunthorpe
2021-11-24 19:09 ` David Hildenbrand
2021-11-24 23:11 ` Jason Gunthorpe
2021-11-30 15:52 ` David Hildenbrand
2021-11-24 18:37 ` David Hildenbrand
2021-11-24 14:37 ` Vlastimil Babka
2021-11-24 14:41 ` David Hildenbrand
2021-11-16 18:36 ` Matthew Wilcox
2021-11-16 18:44 ` Drew DeVault
2021-11-16 18:55 ` Jens Axboe
2021-11-16 19:21 ` Vito Caputo
2021-11-16 19:25 ` Drew DeVault
2021-11-16 19:46 ` Vito Caputo
2021-11-16 19:41 ` Jens Axboe
2021-11-17 22:26 ` Johannes Weiner
2021-11-17 23:17 ` Jens Axboe
2021-11-18 21:58 ` Andrew Morton
2021-11-19 7:41 ` Drew DeVault
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=YYPt1PaGtiSLvyKw@rei \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
/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