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 9C18EC433EF for ; Mon, 25 Oct 2021 15:48:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 76E9960EBD for ; Mon, 25 Oct 2021 15:48:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233008AbhJYPuq (ORCPT ); Mon, 25 Oct 2021 11:50:46 -0400 Received: from shells.gnugeneration.com ([66.240.222.126]:39794 "EHLO shells.gnugeneration.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232776AbhJYPuq (ORCPT ); Mon, 25 Oct 2021 11:50:46 -0400 X-Greylist: delayed 335 seconds by postgrey-1.27 at vger.kernel.org; Mon, 25 Oct 2021 11:50:46 EDT Received: by shells.gnugeneration.com (Postfix, from userid 1000) id EC5A11A401FF; Mon, 25 Oct 2021 08:42:47 -0700 (PDT) Date: Mon, 25 Oct 2021 08:42:47 -0700 From: Vito Caputo To: Drew DeVault Cc: io-uring@vger.kernel.org Subject: Re: Is IORING_REGISTER_BUFFERS useful given the current default RLIMIT_MLOCK? Message-ID: <20211025154247.fnw6ec75fmx5tkqy@shells.gnugeneration.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: io-uring@vger.kernel.org On Mon, Oct 25, 2021 at 03:58:33PM +0200, Drew DeVault wrote: > The current default for RLIMIT_MLOCK is set to 64 KiB. This is not much! > This limit was set to this value in 2008 at the request of GnuPG. > > I understand that the main audience of io_uring is high-performance > servers and such, where configuring the rlimits appropriately is not a > particularly burdensome ask. However, this dramatically limits the > utility of IORING_REGISTER_BUFFERS in the end-user software use-case, > almost such that it's entirely pointless *without* raising the mlock > rlimit. > > I wonder if we can/should make a case for raising the default rlimit to > something more useful for $CURRENTYEAR? If not for the gpg precedent cited, I'd say it's obviously distribution-specific defaults choice territory when it's as simple as what's preset in /etc/security/limits.conf. Systemd has also been getting its hands a bit dirty in the area of bumping resource limits, which I'm not sure how I feel about. But it does illustrate how downstream is perfectly capable of managing these limits on behalf of users. Regards, Vito Caputo