From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 05FB3C4332F for ; Thu, 4 Nov 2021 14:44:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D65E0611EE for ; Thu, 4 Nov 2021 14:44:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231318AbhKDOrH (ORCPT ); Thu, 4 Nov 2021 10:47:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47188 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229505AbhKDOrF (ORCPT ); Thu, 4 Nov 2021 10:47:05 -0400 Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D6362C061714 for ; Thu, 4 Nov 2021 07:44:27 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id n128so7143589iod.9 for ; Thu, 04 Nov 2021 07:44:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20210112.gappssmtp.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=7AsHwRp7W89TDu4CaaCkCBJjXNZdEdmiMQdVy3czbNY=; b=b5j9TCl/4nB3OfsBXecWlEHpNTejWrzDGHJMDjMh4rvTnH2et0rEOnFDSOpV1PujBN FVuNBLWL9344adIZyFhDQ6qREQUqe1N7XWUD5a5+GSZThhUlUEQiYNHWkoTCQgjBzA9h KfuJLh3ru268LY2GHUt9UHGuWZiZN6OIe5cYQ/sss2x3YHb0FtDvFBPd+umjgUt9ONUf vqrsCcMDEV+LLLMidxlm7dNt5VPyip2KjBbyfEeGFPmlNvtu8H5Es1SElYki9q5vhx4A uTK3WVwTydAQ3y77SsSk+MWALuKUNQHauoxQzsOYR5HD7VPpfleUt90kW1cNfppvbpi2 cFVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=7AsHwRp7W89TDu4CaaCkCBJjXNZdEdmiMQdVy3czbNY=; b=2JZaNFr3syoz0NzN2sYKEmwkUpf1QI+oKOAkXhMhv8IayOrTzl2gtTi37RSvL8dlcp MXSn8nPtXCgqLE0w+5SRzzDVbcYWtwVnbFIndlmHx6PWLQdTKhANCG652tPTefn4N6WR 0+du2NLMm30oBbRJqCnk+XWYLLMRVRlukrz6Wnr2bXRiiT66/pv8vHfTRosdNHYztCVp MIBN3RKyXC1ZKm6IsuNkFMkHl0wFSEy14rrVrC1OligO2xXQPRtNU6C1Q5QVfD4nqh92 K3m/DZ+EiJl/t7+Upq5bi0aLz46iZlZSxZRnqMGZeosjQBra+Qi4lvhsj0jXXeWtzRn5 fBTA== X-Gm-Message-State: AOAM531yzXlLYvxkuXcYRQTseV4qNxZoeM1PDg3xhu3y+3isxg6hbf1h WLem89nUr9j2+Nc/7BIiMsFiMQ== X-Google-Smtp-Source: ABdhPJya0s5iJuHzAorLG6/MYzrxzuKhIBQIuXwGk2hiSyk/aD1paAV9Hp8M5wwf+dpBZEX2r5j+WA== X-Received: by 2002:a6b:fe11:: with SMTP id x17mr7846300ioh.131.1636037066269; Thu, 04 Nov 2021 07:44:26 -0700 (PDT) Received: from [192.168.1.30] ([207.135.234.126]) by smtp.gmail.com with ESMTPSA id t6sm3096389iov.39.2021.11.04.07.44.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 04 Nov 2021 07:44:25 -0700 (PDT) Subject: Re: [PATCH] Increase default MLOCK_LIMIT to 8 MiB To: Cyril Hrubis Cc: Drew DeVault , linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, io-uring@vger.kernel.org, Pavel Begunkov , Andrew Morton References: <20211028080813.15966-1-sir@cmpwn.com> From: Jens Axboe Message-ID: 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: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 Andrew, care to pick this one up for 5.16? -- Jens Axboe