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 D83DDC7619A for ; Tue, 11 Apr 2023 09:10:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 444D3280064; Tue, 11 Apr 2023 05:10:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3CB5E28005D; Tue, 11 Apr 2023 05:10:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1F7C8280064; Tue, 11 Apr 2023 05:10:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 0ACBE28005D for ; Tue, 11 Apr 2023 05:10:30 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id D3C3C1C6645 for ; Tue, 11 Apr 2023 09:10:29 +0000 (UTC) X-FDA: 80668539378.25.9E937E1 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf14.hostedemail.com (Postfix) with ESMTP id D8F9B100021 for ; Tue, 11 Apr 2023 09:10:27 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b="F/GtwlKh"; spf=pass (imf14.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1681204228; h=from:from:sender: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=J8OA3wgt+Z7nlPBRmZK8bnpZsdI2d7MNXaYAdmJPsgA=; b=zei3e3/+SQQF0ymExOQO2Bk3JU1tYu+wbtxgGUeL8qV3XnYWdaL3VIKnzZwcUpXOywKa01 TusuNzAN0DSk2bZEWNZCUvgZNCCd/aVMhJsxHzeHpo/Xpbdu46YO70+OBPWG9CClq3bxqW hTlpojor8utR7nE/RI8M+DILX5rJ2OY= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b="F/GtwlKh"; spf=pass (imf14.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1681204228; a=rsa-sha256; cv=none; b=RAILSqBzWKKbquDdtG59ZF67uSkKhIGWbnijxiSuUD7czSHlSZqRfupx/6uEzjOlA0Oj+B FKGtygF0h9eM0jbBZYVYxZstOWA6n/QyBayiNDzQYQPk0Oc83F6Ii8FL7vUHP2XOHO7WfK HtGSgCpUnOSPd5n+kAGYE7yVADvvw8E= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 2786F21A62; Tue, 11 Apr 2023 09:10:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1681204226; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=J8OA3wgt+Z7nlPBRmZK8bnpZsdI2d7MNXaYAdmJPsgA=; b=F/GtwlKhIk6gdskzQIDdvelDeOaGATFGEdUdGAJRZ0+M/AzoL/mXWsiWKdBP7p6hsmGO59 4HVw0kozzIL26HT6VfwUn7KEKjYxTMUGEEG0uWx0ZnCjvBrslPgt8pu3NYTmEkEhr3XplX znbWPl/iaqrIVPxft/0avEwyyDPAoZs= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 032A313519; Tue, 11 Apr 2023 09:10:25 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id TX0WOgEkNWTPHwAAMHmgww (envelope-from ); Tue, 11 Apr 2023 09:10:25 +0000 Date: Tue, 11 Apr 2023 11:10:25 +0200 From: Michal Hocko To: Shaun Tancheff Cc: Johannes Weiner , Vladimir Davydov , Shaun Tancheff , Andrew Morton , cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] memcg: Default value setting in memcg-v1 Message-ID: References: <20230406091450.167779-1-shaun.tancheff@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230406091450.167779-1-shaun.tancheff@gmail.com> X-Stat-Signature: fqyya3zx163mwydt4fkbzyaf6ygdn3b5 X-Rspam-User: X-Rspamd-Queue-Id: D8F9B100021 X-Rspamd-Server: rspam06 X-HE-Tag: 1681204227-235258 X-HE-Meta: U2FsdGVkX1+8ER3Y8XIYDlwp+afVOtPsbOBX1sbCIgJp0D50SmJd1kw7jilbs1sYax0pgArqIWvPLGgEnAAg88CcCzz/psTIklO+NUvrbGaSA7KL2YkdOjCx9FantpCm/qrl1eDLP3HSIDUm4YCvEtwrj6LZStbElRzKGkXWlq/lykmL2omHczSh+2VXJz0yQ1054Pdii83ApSQWEAFPYBAYHuivtACSl2RUIjWtIYfjJfZ10XEGIwRqTFeXWvEwgQIQK7OhldSWcpgFC9I8fCxjhgaebOeyxqTwsoaHLH9ufTskpliClwf6cEHzeZL8I7f3Mo7OIg1Rgo9FVbncnYZTfxCfytLDcBfwwHK5lXFZnpUa8NyakzOKbI/1Uwem4F0oO+X7W70RW4JjzX7GPwqs1QGHfdAcEAnxxvviAwZSZoNzBPlzlkx99kQjTwzEl5oeis4W2nsxZDFjqdsERcyir7HxIpCG4QUPaHXEj1Op8RKO/S8rXheFsPO8BXu5n1+gIu5ep/rzFL61xSlm187hoSTuNUwkKZtFncutBZ7TKR/YhPwgdXziW8r0LnSoZ0cRR/8SQGsuT9NQaQbXnLnfGEtR2tuMBqVteySkC7X+h1+YjGrZ7Dm6Y7sFxpYbxuaoDDs+6uGtfzZjuEQGCi0xasE0yNAfvVUEclROJWh+iErQFLorrpUBhAS6vI9V5PUY0hfqmMwbTEj0vfQ70dyJRKgpSZjlTsIzfIwlxnxS/V5N8rlfiS8L9FKErXU4KB7qe+22DkHkHVgQJ8hhLqCV2Xv7DdiR+X5jDCCu4devKmAzyEJbyJZqcvaWcJWAvlnXk5yENTbBslEwWQnkKyGwDR9dHjA/ZiR3mtiPkfCvIL0TX7T8uWh/tHnhPT+JeZ3xSrKZO0lhRkwmoS7dbRZJeVC97okyqGt1er+WZ0Wc0ELfBL2jlKgA06/baNHR3ivllPbsiaspSkAJv1K e+hLDnNp 1Rg5RK4RrcLbF7odJH12heTI9SgmRyjoxdof1UfXdlMjBUvSDH04vaRme/uyJBsagPV8Su8kaUuBcJvee6eGTiGMSlu2q8excHM/KdttQIZ+ah8MbP+7LV2ubKAcpvqj+r/q4LhL/kASYNuGvgh5IaJip/0+Gx3RJJh2yOraQpCi3+WOQm6ylBIixafTdZr++FZTQTkH1jrQLnDqV3f7rpt1HdwFpDDZC/WIa6JRSZpsXMIvrRQsw8SFpYCucj1FnZhhRMCCKiqmHIg/JjGGJ87fjHsWYuoc9zGGqpbZNGmy7Mo4OOk/fBsvavcbUQydKqXUc 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 Thu 06-04-23 16:14:50, Shaun Tancheff wrote: > From: Shaun Tancheff > > Setting min, low and high values with memcg-v1 > provides bennefits for users that are unable to update > to memcg-v2. min, low and high limits are cgroup v2 concepts which are not a fit for v1 implementation. The primary reason why v2 interface has been created was that existing v1 interfaces and internal constrains (most notably soft limit and tasks in inter nodes for memcg) were not reformable. It is really hard to define a proper semantic for memory protection when inter node tasks can compete with hierarchy beneath. > Setting min, low and high can be set in memcg-v1 > to apply enough memory pressure to effective throttle > filesystem I/O without hitting memcg oom. This is not a proper way to achieve that. As I've already state in the previous submission of a similar patch (20230330202232.355471-1-shaun.tancheff@gmail.com), cgroup v1 dirty data throttling has some downsides because it cannot effectively throttle GFP_NOFS allocations. One way around that is to reduce the dirty data limit to prevent from over dirty memcg LRUs. I would recommend to move forward to cgroup v2 though. > This can be enabled by setting the sysctl values: > vm.memcg_v1_min_default > vm.memcg_v1_low_default > vm.memcg_v1_high_default > > When a memory control group is newly crated the > min, low and high values are set to percent of the > maximum based on the min, low and high default > values respectively. This also looks like an anti-pattern in the cgroup world. For two reasons. First of all min, low (reclaim protection) is hierarchical and global default value makes a very little sense for anything than flat hierarchies and even then it makes it really easy to misconfigure system too easily. Also percentage is a very suboptimal interface in general as the granularity is just too coarse for anything than small limits. > This resolves an issue with memory pressure when users > initiate unbounded I/O on various file systems such as > ext4, XFS and NFS. Filesystems should still be controllable by dirty limits. This might lead to a suboptimal IO throughput but this might be a better workaround if you cannot afford to move to cgroup v2. V1 interface is considered legacy and support is limited. New features are only added if there absolutely is not other way around to keep legacy applications running. HTH -- Michal Hocko SUSE Labs