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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2561DC433F5 for ; Mon, 22 Nov 2021 17:12:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8CA3A6B0073; Mon, 22 Nov 2021 12:11:46 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8799B6B0075; Mon, 22 Nov 2021 12:11:46 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 741826B0078; Mon, 22 Nov 2021 12:11:46 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0160.hostedemail.com [216.40.44.160]) by kanga.kvack.org (Postfix) with ESMTP id 67D3B6B0073 for ; Mon, 22 Nov 2021 12:11:46 -0500 (EST) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 3071A87C9D for ; Mon, 22 Nov 2021 17:11:36 +0000 (UTC) X-FDA: 78837207792.26.291D0A0 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf24.hostedemail.com (Postfix) with ESMTP id AD359B0000B2 for ; Mon, 22 Nov 2021 17:11:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1637601095; 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=Phf2QrzzmaDIwGVfZVve7wU0yQ9D8hvAWEdQ6KPMNRo=; b=fu8ut0QepbdyJPHFhIEb44AtwVrakPbqcwRF0YspGH1NCqmUm73rBVK73nSFI/H9iVHWN9 zuyodh1rYc7vEOaPcDX20nOGAS0GZtm2ACnjbxDUDU4CWo55mhqWzVhgPSEse5yZ+dEmoP gHhVgrcBKhpQm21pRelhVB3Jq832LKk= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-144-9VCfOKrzPgK8uN3wGo34gA-1; Mon, 22 Nov 2021 12:11:31 -0500 X-MC-Unique: 9VCfOKrzPgK8uN3wGo34gA-1 Received: by mail-wr1-f72.google.com with SMTP id h13-20020adfa4cd000000b001883fd029e8so3302989wrb.11 for ; Mon, 22 Nov 2021 09:11:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:cc:references:from:organization:subject :in-reply-to:content-transfer-encoding; bh=Phf2QrzzmaDIwGVfZVve7wU0yQ9D8hvAWEdQ6KPMNRo=; b=OL9971Xr2HKcbOkG76LqLH64/Vu/671yKT1BrZ+45TaZUPOGiUDwJI35pnFbIGU2Pm Vu8ILo361tzG9Vzh3yFZxvULiBWOnPIWVnGqEbg4ScPjm+1niueaeegMwin6B0XVZvro 39LWUAZF8wX/lO6q/BHcH9Q82oSixFAaEsdPx9rS7g7e8C9c0PhPCvLBZGrbfPg9kgTS ghezGovWsoI+l437yRyRTMzPO6VfjHjICOWagFVbbhji7EWC1oYp8ZWr+lJLHvxdq1+c 49965xW5r/YIKIcU3fmi0LnmGtweFv9KtneU6cDdg4mjI/O2Z2CtpMMSNevncn8xd+Rk FwMw== X-Gm-Message-State: AOAM530vR0fAcd0jJfyojNLEpUumOjOUH3NovfdOU+rMaq+zS9ZvBw1w 5mSGJNFNKUT/X+hQ9o5ZkP8ypMZMufXwC/wWliG/LkxYHnSJCZ+pD56oJPqYLvx0yaDEx1V23M6 whh/x4HOpQRw= X-Received: by 2002:a7b:cd93:: with SMTP id y19mr30737774wmj.190.1637601090610; Mon, 22 Nov 2021 09:11:30 -0800 (PST) X-Google-Smtp-Source: ABdhPJwJSOfXqMAnLV5Q/tuhdq3GNQ8VLl419MW+cfbNy8G3bRV/AYoyovM3ensDWzOdfrrIx6af/Q== X-Received: by 2002:a7b:cd93:: with SMTP id y19mr30737727wmj.190.1637601090332; Mon, 22 Nov 2021 09:11:30 -0800 (PST) Received: from [192.168.3.132] (p5b0c667b.dip0.t-ipconnect.de. [91.12.102.123]) by smtp.gmail.com with ESMTPSA id k37sm11072331wms.21.2021.11.22.09.11.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 22 Nov 2021 09:11:29 -0800 (PST) Message-ID: Date: Mon, 22 Nov 2021 18:11:28 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 To: Andrew Morton , Drew DeVault Cc: Ammar Faizi , linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, io_uring Mailing List , Jens Axboe , 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> <20211116114727.601021d0763be1f1efe2a6f9@linux-foundation.org> <20211116133750.0f625f73a1e4843daf13b8f7@linux-foundation.org> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH] Increase default MLOCK_LIMIT to 8 MiB In-Reply-To: <20211116133750.0f625f73a1e4843daf13b8f7@linux-foundation.org> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: AD359B0000B2 X-Stat-Signature: zn69py8iok1jikxp51hte9e91mfbw6f6 Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=fu8ut0Qe; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf24.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=david@redhat.com X-HE-Tag: 1637601092-446743 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 16.11.21 22:37, Andrew Morton wrote: > On Tue, 16 Nov 2021 20:48:48 +0100 "Drew DeVault" wrote: > >> On Tue Nov 16, 2021 at 8:47 PM CET, Andrew Morton wrote: >>> Well, why change the default? Surely anyone who cares is altering it >>> at runtime anyway. And if they are not, we should encourage them to do >>> so? >> >> I addressed this question in the original patch's commit message. > > Kinda. > > We're never going to get this right, are we? The only person who can > decide on a system's appropriate setting is the operator of that > system. Haphazardly increasing the limit every few years mainly > reduces incentive for people to get this right. > > And people who test their software on 5.17 kernels will later find that > it doesn't work on 5.16 and earlier, so they still need to tell their > users to configure their systems appropriately. Until 5.16 is > obsolete, by which time we're looking at increasing the default again. > > I don't see how this change gets us closer to the desired state: > getting distros and their users to configure their systems > appropriately. > My 2 cents: while we should actually try to avoid new FOLL_LONGTERM users where possible, we introduce more (IOURING_REGISTER_BUFFERS) to be consumed by ordinary, unprivileged users. These new features, *when used* require us to raise the MLOCK_LIMIT. Secretmem is similar, but for now it rather "replaces" old mlock usage and IIRC has similarly small memory demands; that might change in the future, though. Why is FOLL_LONGTERM bad? Not only does it prevent swapping like mlock does, the pages are also unmovable in memory, such that they cannot be moved around, for example, for memory compaction. Well, I'm not too mad about IOURING_REGISTER_BUFFERS, it actually helped me to write a simple reproducer for the COW issues we have in upstream mm, and can be quite beneficial in some setups. Still, I think it should be used with care depending on the actual environment. So, just because a new feature is around that could be used, does it mean that we should adjust our kernel default? I'd say in this case, rather not. Distributions, or much better, the responsible admin, should make such decisions, knowing the environment and the effect this could have. (I know that we can similarly trigger allocation of a lot of unmovable memory using other means by malicious user space; but that is rather something to limit or handle in the future IMHO) -- Thanks, David / dhildenb