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 217D9C433F5 for ; Thu, 18 Nov 2021 21:59:12 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A49A561248 for ; Thu, 18 Nov 2021 21:59:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org A49A561248 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 140E16B0072; Thu, 18 Nov 2021 16:59:01 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0EFC66B0073; Thu, 18 Nov 2021 16:59:01 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EF9B46B0074; Thu, 18 Nov 2021 16:59:00 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0241.hostedemail.com [216.40.44.241]) by kanga.kvack.org (Postfix) with ESMTP id DDEBF6B0072 for ; Thu, 18 Nov 2021 16:59:00 -0500 (EST) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 8EE2918355E76 for ; Thu, 18 Nov 2021 21:58:50 +0000 (UTC) X-FDA: 78823416420.22.709BA6B Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf06.hostedemail.com (Postfix) with ESMTP id EA3F2801AB1B for ; Thu, 18 Nov 2021 21:58:48 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id DD99661220; Thu, 18 Nov 2021 21:58:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1637272729; bh=qRyDXwaTe3qUn3q5rUCnxzGRTuX1TapIqNvlx4tcXq8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=xVqkWFkv5mEQQCTHGzAUSOSOOpzbkwrzNTEjZhCij945qEou5kB0ARDQ8HOY50KJs dFf7SMnq735dbLhsJv0UuGx5ni+N28ON008MIQI8nhme70J9p+5Jd4WCwE6i6TESmN TZXV5bsYmQAchyzzs6EI4mNzygJz9Bfs5eWqyRF4= Date: Thu, 18 Nov 2021 13:58:46 -0800 From: Andrew Morton To: Jens Axboe Cc: Johannes Weiner , Ammar Faizi , Drew DeVault , linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, io_uring Mailing List , Pavel Begunkov , linux-mm@kvack.org Subject: Re: [PATCH] Increase default MLOCK_LIMIT to 8 MiB Message-Id: <20211118135846.26da93737a70d486e68462bf@linux-foundation.org> In-Reply-To: References: <20211028080813.15966-1-sir@cmpwn.com> <593aea3b-e4a4-65ce-0eda-cb3885ff81cd@gnuweeb.org> <20211115203530.62ff33fdae14927b48ef6e5f@linux-foundation.org> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: EA3F2801AB1B X-Stat-Signature: 3kazgey34iy1q8oacgac7f43jdzjj4yg Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=xVqkWFkv; dmarc=none; spf=pass (imf06.hostedemail.com: domain of akpm@linux-foundation.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org X-HE-Tag: 1637272728-770075 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 Wed, 17 Nov 2021 16:17:26 -0700 Jens Axboe wrote: > On 11/17/21 3:26 PM, Johannes Weiner wrote: > >> Link: https://lkml.kernel.org/r/20211028080813.15966-1-sir@cmpwn.com > >> Signed-off-by: Drew DeVault > >> Acked-by: Jens Axboe > >> Acked-by: Cyril Hrubis > >> Cc: Pavel Begunkov > >> Signed-off-by: Andrew Morton > > > > Acked-by: Johannes Weiner > > > > As per above, I think basing it off of RAM size would be better, but > > this increase is overdue given all the new users beyond mlock(), and > > 8M is much better than the current value. > > That's basically my reasoning too. Let's just get something going that > will at least unblock some valid use cases, and not get bogged down with > aiming for perfection. The latter can happen in parallel, but it should > not hold it up imho. Nobody's aiming for perfection. We're discussing aiming for "better". What we should have done on day one was to set the default MLOCK_LIMIT to zero bytes. Then everyone would have infrastructure to tune it from userspace and we wouldn't ever have this discussion.