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 F1D68C433F5 for ; Tue, 16 Nov 2021 06:32:39 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 585F463218 for ; Tue, 16 Nov 2021 06:32:39 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 585F463218 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=cmpwn.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id D41916B009F; Tue, 16 Nov 2021 01:32:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CF14A6B00A0; Tue, 16 Nov 2021 01:32:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BDFF66B00A5; Tue, 16 Nov 2021 01:32:38 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0226.hostedemail.com [216.40.44.226]) by kanga.kvack.org (Postfix) with ESMTP id AD21E6B009F for ; Tue, 16 Nov 2021 01:32:38 -0500 (EST) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 66E6586319 for ; Tue, 16 Nov 2021 06:32:38 +0000 (UTC) X-FDA: 78813824796.02.9A95607 Received: from out1.migadu.com (out1.migadu.com [91.121.223.63]) by imf08.hostedemail.com (Postfix) with ESMTP id 7C91C30000AE for ; Tue, 16 Nov 2021 06:32:20 +0000 (UTC) MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpwn.com; s=key1; t=1637044355; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=grpzxEghztc5Qa8gVHDO4iWZ6E6Q47JzcLyl8tfJjZw=; b=RODkIUUmmlH8V+ixcJqD/r8M5N4EE/o9UdaursBlFlxIkiBAi7Gzx6ZWvKSnxZ/ZaN3owQ kcOQpYdgwdRiSs3KpUv2oA/965DQjtuRQ3OeNRgEnKfzZ02xyVlJlC1uwHYA3JDVxuR2/u zw5VQQxveqVcXQpyGLiDhI3fTSInjbK8naIgrpOkc9mn2bxuQeu8+Osa39MbnIdHV/QAhS 1yd7SfQ50nEuSzLENCuOEQKKfFZ4nY6BRCGN1eQ+wLN66Mv5ceeloX1AT5Sw3Zys0lyTv0 0Y2fWNi65rcr8OQHL2cH98ZPUNiNi77MQUCwwnEJWGS1sjSDKGyE5Pd/5x5KRg== Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Tue, 16 Nov 2021 07:32:33 +0100 Message-Id: Cc: , , "io_uring Mailing List" , "Jens Axboe" , "Pavel Begunkov" , Subject: Re: [PATCH] Increase default MLOCK_LIMIT to 8 MiB X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: "Drew DeVault" To: "Andrew Morton" , "Ammar Faizi" References: <20211028080813.15966-1-sir@cmpwn.com> <593aea3b-e4a4-65ce-0eda-cb3885ff81cd@gnuweeb.org> <20211115203530.62ff33fdae14927b48ef6e5f@linux-foundation.org> In-Reply-To: <20211115203530.62ff33fdae14927b48ef6e5f@linux-foundation.org> X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: sir@cmpwn.com X-Stat-Signature: 97ia86gm9bf9fj49jrzqm66ktie8akmd Authentication-Results: imf08.hostedemail.com; dkim=temperror ("DNS error when getting key") header.d=cmpwn.com header.s=key1 header.b=RODkIUUm; spf=temperror (imf08.hostedemail.com: error in processing during lookup of sir@cmpwn.com: DNS error) smtp.mailfrom=sir@cmpwn.com; dmarc=temperror reason="SPF/DKIM temp error" header.from=cmpwn.com (policy=temperror) X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 7C91C30000AE X-HE-Tag: 1637044340-504863 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue Nov 16, 2021 at 5:35 AM CET, Andrew Morton wrote: > Unfortunately I didn't know about this until Nov 4, which was formally > too late for 5.16. I guess I could try to sneak it past Linus if > someone were to send me some sufficiently convincing words explaining > the urgency. I don't think it's that urgent, but I also wouldn't protest if someone wants to usher it in sooner rather than later. > And a question: rather than messing around with a constant which will > need to be increased again in a couple of years, can we solve this one > and for all? For example, permit root to set the system-wide > per-process max mlock size and depend upon initscripts to do this > appropriately. Not sure I understand. Root and init scripts can already manage this number - the goal of this patch is just to provide a saner default.