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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 08873C4361B for ; Tue, 15 Dec 2020 13:08:51 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7CBD022286 for ; Tue, 15 Dec 2020 13:08:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7CBD022286 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=cmpxchg.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id CE8576B0070; Tue, 15 Dec 2020 08:08:48 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C97FB6B0071; Tue, 15 Dec 2020 08:08:48 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B870C6B0072; Tue, 15 Dec 2020 08:08:48 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0054.hostedemail.com [216.40.44.54]) by kanga.kvack.org (Postfix) with ESMTP id A21F16B0070 for ; Tue, 15 Dec 2020 08:08:48 -0500 (EST) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 694512488 for ; Tue, 15 Dec 2020 13:08:48 +0000 (UTC) X-FDA: 77595546336.13.feet32_5910f4e27423 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin13.hostedemail.com (Postfix) with ESMTP id 3FB4618140B69 for ; Tue, 15 Dec 2020 13:08:48 +0000 (UTC) X-HE-Tag: feet32_5910f4e27423 X-Filterd-Recvd-Size: 4706 Received: from mail-ej1-f44.google.com (mail-ej1-f44.google.com [209.85.218.44]) by imf07.hostedemail.com (Postfix) with ESMTP for ; Tue, 15 Dec 2020 13:08:47 +0000 (UTC) Received: by mail-ej1-f44.google.com with SMTP id w1so22920701ejf.11 for ; Tue, 15 Dec 2020 05:08:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=D2qw/XdFOBJxZPNw2vsi9R2N0jtLRJXUxqXyTXj+FHw=; b=PdIXQE+Qng2oW8A7mDDMKmVZHZWSxx2uRm4LeY/1cJsma/Z+R1GdIAAR6qCKOxGSxa Izzc+bt5ipZkcO1q7F2qlNQ4Q5nhQxyZhxQr8uP9eM+MEkm7DdfAnWjPvTeANKBxQz+Y gBUOEm4d8lKuWJDoVd4I9UCT8OMz01kzBeNfx14a2Z0Q+4+sZvZ6utwR+ioh1iXsAeBg PT5hEg5E4fkRw2xU2Ofl6LO47XxvecyLNfWtaydFA1Egt8SL7p3UckrTav6N0IilvgSj /prhm8OIISjFNM23a8ocEt1DpIlpC76cLJoIzB6BPbRyeCOgT/pOMVY5VTR0UjE+5wgz 3cpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=D2qw/XdFOBJxZPNw2vsi9R2N0jtLRJXUxqXyTXj+FHw=; b=OHe+BgltGge7xo1pvp7VMeU65DxuTma8OQoO724on+ULZUuxgcjroSv1c9kDjLtlRE pcvWU52vP4QClI4AR7kASWRMsVSm8eREM1NERgJpjKAoh0ChpfGI9vtR6Vv/lqLk/FwV PwpYphJVIsnl0/qMYaX2+kIyg2+bgtLdOCG6+6Hw6WTABcP0CrhKTzFdDMFOZX1dDYew Tv/9JzCh0gKs7U3ebNTfPtHJ0oi3wJFzyBvPadfWmTkY50WINeCAaqg1wylzRJSbou1D OS+aSp7z5t9w4M0UCdOzT92QOz8sRrB0wxu6URl0IlC5Vagp/HR76MU4TO1llEfMAPjI YpsQ== X-Gm-Message-State: AOAM531FlAoaX//yhx4RVXFMFvdk7Fv54ZQ8Sp71UiGmlAlwokVyYjwj bIy96kQvDdvyVvY0TRT+TqPnLQ== X-Google-Smtp-Source: ABdhPJwXZotyd8BhqWanG/W9GlwJ9+LTG9ORIqYNYEMCg1JmUoTTzZ2XgYgjc+610JwCC6JmNzfUNQ== X-Received: by 2002:a17:906:add7:: with SMTP id lb23mr28131007ejb.352.1608037726300; Tue, 15 Dec 2020 05:08:46 -0800 (PST) Received: from localhost ([2620:10d:c093:400::5:d6dd]) by smtp.gmail.com with ESMTPSA id de12sm18215742edb.82.2020.12.15.05.08.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 15 Dec 2020 05:08:45 -0800 (PST) Date: Tue, 15 Dec 2020 14:06:38 +0100 From: Johannes Weiner To: Chunyu Hu Cc: linux-mm@kvack.org, guro@fb.com, akpm@linux-foundation.org Subject: Re: Question about admin_reserve_kbytes in GUESS mode Message-ID: <20201215130638.GB379720@cmpxchg.org> References: <223826327.62466770.1608031937021.JavaMail.zimbra@redhat.com> <1273738630.62467759.1608032559889.JavaMail.zimbra@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1273738630.62467759.1608032559889.JavaMail.zimbra@redhat.com> 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, Dec 15, 2020 at 06:42:39AM -0500, Chunyu Hu wrote: > Hello experts, > > I find admin_reserve_kbytes is not working as documented since > commit 8c7829b04c523cdc(mm: fix false-positive OVERCOMMIT_GUESS failures). > > Before that, available free pages are used to determine the allocation check, and admin_reserve_kbytes > was honored in the default GUESS over_commit mode. While after that commit, admin_reserve_kbytes > is not honored in default mode any more. This looks like break the sysctl usage? > > Documentation/admin-guide/sysctl/vm.rst: > > admin_reserve_kbytes > ==================== > > The amount of free memory in the system that should be reserved for users > with the capability cap_sys_admin. > > admin_reserve_kbytes defaults to min(3% of free pages, 8MB) > > That should provide enough for the admin to log in and kill a process, > if necessary, under the default overcommit 'guess' mode. Thanks for the report. Can you elaborate on your usecase a bit? How you rely on the knob, and how it's not working properly now? It would be easy enough to this check back to the simplified formula, I'm just having some trouble picturing how it would be useful. The knob never (not since git, anyway) behaved the way it's documented here. We don't track total virtual memory; instead the checks apply to individual allocations. So it was never true that we reserve 3% of RAM for admins. Rather, the biggest single mmap() request an admin could do was 100% of RAM, whereas for unprivileged users it was 97% of RAM. But you could always do two or more requests of that size in a row anyway. It's not clear to me that this is a meaningful distinction.