Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH] Increase default MLOCK_LIMIT to 8 MiB
To:     Cyril Hrubis <chrubis@suse.cz>
Cc:     Drew DeVault <sir@cmpwn.com>, linux-kernel@vger.kernel.org,
        linux-api@vger.kernel.org, io-uring@vger.kernel.org,
        Pavel Begunkov <asml.silence@gmail.com>,
        Andrew Morton <akpm@linux-foundation.org>
References: <20211028080813.15966-1-sir@cmpwn.com>
 <cc3d7fac-62e9-fe11-0cf1-3d9528d191a0@kernel.dk> <YYPt1PaGtiSLvyKw@rei>
From:   Jens Axboe <axboe@kernel.dk>
Message-ID: <fdf1c610-6c9a-befd-a284-b8a552b4c225@kernel.dk>
Date:   Thu, 4 Nov 2021 08:44:24 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <YYPt1PaGtiSLvyKw@rei>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

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@suse.cz>

Andrew, care to pick this one up for 5.16?

-- 
Jens Axboe