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 5F74AC433EF for ; Tue, 16 Nov 2021 19:18:45 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0A1B263223 for ; Tue, 16 Nov 2021 19:18:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 0A1B263223 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 8F8FC6B006C; Tue, 16 Nov 2021 14:18:44 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8A7E06B0073; Tue, 16 Nov 2021 14:18:44 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 797096B007B; Tue, 16 Nov 2021 14:18:44 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0125.hostedemail.com [216.40.44.125]) by kanga.kvack.org (Postfix) with ESMTP id 6C59A6B006C for ; Tue, 16 Nov 2021 14:18:44 -0500 (EST) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 22F9F1813121E for ; Tue, 16 Nov 2021 19:18:44 +0000 (UTC) X-FDA: 78815755368.22.A8A5BC0 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf13.hostedemail.com (Postfix) with ESMTP id 85D6B1059B19 for ; Tue, 16 Nov 2021 18:36:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=JEcbbh/dVkVptbrXWN3GozTnEzbwvPLEPedTKPD53aQ=; b=mA5jxu3sy0X3+aUkFrrjpR47Fj yYqwQI9T6Ct8fWvCTg/mhpbbeRlReFVm5x70No48tHenfs0ppYqqxUB0OhHKJ2vhlKysqZ57QFdfB 58s/AbXaqmJ66Nqmz4ZAe6ail5OntA13nZguCvb42BNFXbXJ8vU/HeSKif5EpDd7f2KrVMTEmc8SH ekTDgTEbWUOsUI1ao1wB3XtqxrvQaNz9Ko3z62Djdav9mdd1Jf/ePybJZaQiKedJ0YViBu+Rz12ej qXQp9Rg0Dno9l6+/WqIfA4k+z5gtTWG5hydwvXQrySsfqFjlfiym9+S2/SpXu2lk4LngSb+8Un1Ne McvVQPgQ==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1mn3Jd-006zsT-HT; Tue, 16 Nov 2021 18:36:21 +0000 Date: Tue, 16 Nov 2021 18:36:21 +0000 From: Matthew Wilcox To: Andrew Morton Cc: Ammar Faizi , Drew DeVault , linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, io_uring Mailing List , Jens Axboe , Pavel Begunkov , linux-mm@kvack.org Subject: Re: [PATCH] Increase default MLOCK_LIMIT to 8 MiB Message-ID: References: <20211028080813.15966-1-sir@cmpwn.com> <593aea3b-e4a4-65ce-0eda-cb3885ff81cd@gnuweeb.org> <20211115203530.62ff33fdae14927b48ef6e5f@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211115203530.62ff33fdae14927b48ef6e5f@linux-foundation.org> X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 85D6B1059B19 X-Stat-Signature: i5e9p1k6anoba74jrab5wydy5df68c6t Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=mA5jxu3s; dmarc=none; spf=none (imf13.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org X-HE-Tag: 1637087783-636184 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 Mon, Nov 15, 2021 at 08:35:30PM -0800, Andrew Morton wrote: > I'd also be interested in seeing feedback from the MM developers. [...] > Subject: Increase default MLOCK_LIMIT to 8 MiB On the one hand, processes can already allocate at least this much memory that is non-swappable, just by doing things like opening a lot of files (allocating struct file & fdtable), using a lot of address space (allocating page tables), so I don't have a problem with it per se. On the other hand, 64kB is available on anything larger than an IBM XT. Linux will still boot on machines with 4MB of RAM (eg routers). For someone with a machine with only, say, 32MB of memory, this allows a process to make a quarter of the memory unswappable, and maybe that's not a good idea. So perhaps this should scale over a certain range? Is 8MB a generally useful amount of memory for an iouring user anyway? If you're just playing with it, sure, but if you have, oh i don't know, a database, don't you want to pin the entire cache and allow IO to the whole thing?