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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9E4B5C77B73 for ; Tue, 6 Jun 2023 00:09:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233025AbjFFAJV (ORCPT ); Mon, 5 Jun 2023 20:09:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36222 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230328AbjFFAJU (ORCPT ); Mon, 5 Jun 2023 20:09:20 -0400 Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 46E9FFA; Mon, 5 Jun 2023 17:09:18 -0700 (PDT) Received: by mail-pf1-x432.google.com with SMTP id d2e1a72fcca58-654f8b56807so2809326b3a.1; Mon, 05 Jun 2023 17:09:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1686010158; x=1688602158; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date:message-id :reply-to; bh=Z84IZvmzWip89Eeas0z1NQsVyFYK452XIFdNItStgJo=; b=hrqPYRMhlf3i8gMrJ2AXc9LXwaaiJbiN9/s2TQXdJBJ80dtZzCntUtMbGD2yPaR5t5 69JVQjlA6r1ljlN6bELt0TBdxnRRM5Qd38lMvlwgZl3QW2RcW8IKKaMk9TI9vHddTgf0 zWD5mwak9jULNMU8vsOsHm3u3WdT4TsJ7yIj8yNPECuaKt4x8XSYr0GoUBgMmHdf1MLw sfdoULkhA9K/77al/u3iWAO4LxhuwtSxgJWqZyjLUn4wFOt0+Q7XPZ9OM9pTDsfrHgmU gtIxFiWJyF/Cbg4jEBFUi2UoSQBYmOzRMzPIWY0nKZK+LtC4TqdUOZnq6RqFg6/7PBfS OzNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686010158; x=1688602158; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Z84IZvmzWip89Eeas0z1NQsVyFYK452XIFdNItStgJo=; b=T8RzcR88rc/U6LZmeoRYq0G14f/HBeuTkzTVWtavgj9LZs3Y0WL1fC4nTtNvDT7ikB vtXkSe18O0VF07oshLRuLj93hCMekYuOg7wUBKz4K43MTmcFnpCmMjGbfTxBp/kLuv2k imGww3wR9sY1qSR7rJ/5IfvhFSC3HqeGIA/Z3EzsiEWQf5Lc51vELSxJVEY3i1tSWUQf pq3U5jHU4eKaFblw/DOX7nNLBkvhzFs+Y+pf4FY8E42tGLqqjstLVBe9L+bmStgDcHwX 5n9rdjku/u0105NVgWrmwjLIg1LjGxTbfDIxtmCqqzfQXcfNHjcN+F+4lePDk6eBG2Po 3H9g== X-Gm-Message-State: AC+VfDxH761OxAe+Az1rS1RgKN7OxdSh0jMqBtvmv6S/5n1KatKisPWB WH/Ly5CJD8bfaHHXYbXKltXL+w419w0= X-Google-Smtp-Source: ACHHUZ4J0kaXrsmCfj5YsGenu5P3xx5lgX4AqWKOx6ZSv3+F0vXh8bd+gjZiBDMlgN8LucBN8KtSFg== X-Received: by 2002:a05:6a20:7487:b0:10b:3b0d:b05c with SMTP id p7-20020a056a20748700b0010b3b0db05cmr773322pzd.28.1686010157419; Mon, 05 Jun 2023 17:09:17 -0700 (PDT) Received: from localhost (dhcp-72-235-13-41.hawaiiantel.net. [72.235.13.41]) by smtp.gmail.com with ESMTPSA id x7-20020aa793a7000000b006475f831838sm5741516pff.30.2023.06.05.17.09.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 05 Jun 2023 17:09:16 -0700 (PDT) Sender: Tejun Heo Date: Mon, 5 Jun 2023 14:09:15 -1000 From: Tejun Heo To: Dan Schatzberg Cc: Chris Down , Zefan Li , Johannes Weiner , Jonathan Corbet , "open list:CONTROL GROUP (CGROUP)" , "open list:DOCUMENTATION" , open list Subject: Re: [PATCH] Documentation: Clarify usage of memory limits Message-ID: References: <20230601183820.3839891-1-schatzberg.dan@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230601183820.3839891-1-schatzberg.dan@gmail.com> Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org Hello, On Thu, Jun 01, 2023 at 11:38:19AM -0700, Dan Schatzberg wrote: > The existing documentation refers to memory.high as the "main mechanism > to control memory usage." This seems incorrect to me - memory.high can > result in reclaim pressure which simply leads to stalls unless some > external component observes and actions on it (e.g. systemd-oomd can be > used for this purpose). While this is feasible, users are unaware of > this interaction and are led to believe that memory.high alone is an > effective mechanism for limiting memory. > > The documentation should recommend the use of memory.max as the > effective way to enforce memory limits - it triggers reclaim and results > in OOM kills by itself. > > Signed-off-by: Dan Schatzberg Applied to cgroup/for-6.4-fixes. Please see below for a comment tho. > @@ -1213,23 +1213,25 @@ PAGE_SIZE multiple when read back. > A read-write single value file which exists on non-root > cgroups. The default is "max". > > - Memory usage throttle limit. This is the main mechanism to > - control memory usage of a cgroup. If a cgroup's usage goes > + Memory usage throttle limit. If a cgroup's usage goes > over the high boundary, the processes of the cgroup are > throttled and put under heavy reclaim pressure. > > Going over the high limit never invokes the OOM killer and > - under extreme conditions the limit may be breached. > + under extreme conditions the limit may be breached. The high > + limit should be used in scenarios where an external process > + monitors the limited cgroup to alleviate heavy reclaim > + pressure. I think it'd be helpful to provide pointers to oomd and systemd's implementation of it here. Thanks. -- tejun