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 BC537C433F5 for ; Tue, 16 Nov 2021 20:01:13 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3670161A89 for ; Tue, 16 Nov 2021 20:01:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 3670161A89 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.dk Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 8A45F6B007B; Tue, 16 Nov 2021 15:00:45 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 87B016B007E; Tue, 16 Nov 2021 15:00:45 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6F26A6B007D; Tue, 16 Nov 2021 15:00:45 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0030.hostedemail.com [216.40.44.30]) by kanga.kvack.org (Postfix) with ESMTP id 5FC2C6B0074 for ; Tue, 16 Nov 2021 15:00:45 -0500 (EST) Received: from forelay.prod.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by fograve01.hostedemail.com (Postfix) with ESMTP id CB8A11814556A for ; Tue, 16 Nov 2021 19:54:14 +0000 (UTC) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 98D3C84A07 for ; Tue, 16 Nov 2021 19:54:04 +0000 (UTC) X-FDA: 78815844408.02.BCA5D74 Received: from mail-il1-f176.google.com (mail-il1-f176.google.com [209.85.166.176]) by imf31.hostedemail.com (Postfix) with ESMTP id F115210AEEC8 for ; Tue, 16 Nov 2021 18:55:24 +0000 (UTC) Received: by mail-il1-f176.google.com with SMTP id l19so245563ilk.0 for ; Tue, 16 Nov 2021 10:55:43 -0800 (PST) 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=MVFNckbP4TBTfql4KrG+4Ukp5cz3YYPgjjkXF4pzcJc=; b=JtPD1BecFV1FEJH0GTNl7174E9A8l550vBQXhFzRj8USVrgQDYjSwRir9Xp8/SHM6+ p5DaDEQPL1E7ez44Nw+GXeGsnWZBv4nMeaKLhNMdjoo8ixaJq+lv5I4Oc3GXLCyPFpLU pdfGDhs42bKvzHcxpDXZJQpMfiPWCKfjGnHYrHBVcC3CYaUUDAe6Sr5tNCFLWUtpJS+R affOkx50hu9r2ztdpWGJHQNzorEXr8oZ6ytD95+NcEVboAhNHNVfmRN4Wws3p+MeoeC8 OurqThAM+iP3jgMeyeimtHZrKdyQhOV9O53NSlb9TSbSnEiwG/0+XC61qqMSdSNPDsva utGQ== 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=MVFNckbP4TBTfql4KrG+4Ukp5cz3YYPgjjkXF4pzcJc=; b=Yd3yCS0f2fFg7mTPRqB5stOIU4qXIwP1onZVYRhpV55ZhZW6uqxFgAFWsXgSK+Mf5U zyrtqefi0majmJs/vlxaZ8O6MvbqGIpaRThLQiY4PRD9DehHh5YWwZ6hnzY8dj7QG9mU Vmirz2PcG5sgkAHiRZSC0uPakKi8JGG47snfnCnLviTn/mJu+WEO+OQwGPyVdRtY6B/H gbf4K5bEXE1LoEtZ+tUj5l3+MtgokTvfuze4XtqKx+KugHv81M6KSp2Amg4yNWFtaeJN N6eOOpW4HbeJsT2hoZyVjNMQcY+J19XOt5ZXwoTAE0Av4SUMA9oxgDy9i96tZNMfl/Mx Ktbw== X-Gm-Message-State: AOAM532oH3xQgempUOwdFBmDhr2CTg/9G7UoCFWT9IxOkMmcRIxohr/p CqxQEtu7n2Bpdau83YgIM2zfAfMWNEqzLYCT X-Google-Smtp-Source: ABdhPJyYe1hgk2fEdouckIqm5RWn3n7q2+/VfPl6eb5Tmuo3m/ZvVuWgcvs1OKTDYNPTQTqaEyU7tA== X-Received: by 2002:a05:6e02:180e:: with SMTP id a14mr6156312ilv.313.1637088942271; Tue, 16 Nov 2021 10:55:42 -0800 (PST) Received: from [192.168.1.116] ([66.219.217.159]) by smtp.gmail.com with ESMTPSA id a20sm12315511ila.22.2021.11.16.10.55.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 16 Nov 2021 10:55:41 -0800 (PST) Subject: Re: [PATCH] Increase default MLOCK_LIMIT to 8 MiB To: Matthew Wilcox , Andrew Morton Cc: Ammar Faizi , Drew DeVault , linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, io_uring Mailing List , Pavel Begunkov , linux-mm@kvack.org References: <20211028080813.15966-1-sir@cmpwn.com> <593aea3b-e4a4-65ce-0eda-cb3885ff81cd@gnuweeb.org> <20211115203530.62ff33fdae14927b48ef6e5f@linux-foundation.org> From: Jens Axboe Message-ID: Date: Tue, 16 Nov 2021 11:55:41 -0700 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 X-Stat-Signature: 9ief9g5sk3nowjso68cqnpbcqxhg39jp Authentication-Results: imf31.hostedemail.com; dkim=pass header.d=kernel-dk.20210112.gappssmtp.com header.s=20210112 header.b=JtPD1Bec; dmarc=none; spf=pass (imf31.hostedemail.com: domain of axboe@kernel.dk designates 209.85.166.176 as permitted sender) smtp.mailfrom=axboe@kernel.dk X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: F115210AEEC8 X-HE-Tag: 1637088924-12681 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 11/16/21 11:36 AM, Matthew Wilcox wrote: > 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? 8MB is plenty for most casual use cases, which is exactly the ones that we want to "just work" without requiring weird system level modifications to increase the memlock limit. For db etc server setups, you're going to be mucking with the setup anyway, and then I don't see it as a big problem that you'll need to increase it further. Because yes, that won't fit within 8MB if you start doing registered buffers. -- Jens Axboe