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 2847EC0218A for ; Thu, 30 Jan 2025 08:15:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 479732800C8; Thu, 30 Jan 2025 03:15:14 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 42ABB2800C3; Thu, 30 Jan 2025 03:15:14 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2CA042800C8; Thu, 30 Jan 2025 03:15:14 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 0F0A82800C3 for ; Thu, 30 Jan 2025 03:15:14 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 465C31407C3 for ; Thu, 30 Jan 2025 08:15:13 +0000 (UTC) X-FDA: 83063408106.14.7EFEC81 Received: from mail-ej1-f41.google.com (mail-ej1-f41.google.com [209.85.218.41]) by imf29.hostedemail.com (Postfix) with ESMTP id 4184F12000E for ; Thu, 30 Jan 2025 08:15:11 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=ZtLSxnv1; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf29.hostedemail.com: domain of mhocko@suse.com designates 209.85.218.41 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738224911; a=rsa-sha256; cv=none; b=d3vmv8NH6BHNkZBSk178MpFROXBdMmgh91sYGwZpQVNbPrdekhXKg8MmuOlhM84cHWI/5s noeX4IS7WNryNeo4RCxioQNp7QLBw+gVdizGMRbJmny4HlzJRIkA/KwAfaZdUGck0W3TMd NWlptJXSl74nJzlVKrxiyoQxBLQNRBo= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=ZtLSxnv1; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf29.hostedemail.com: domain of mhocko@suse.com designates 209.85.218.41 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738224911; 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=0Yd9VP1y+BPQkS13xsK2KcWh5RNg6hbyGkYuynFoiXU=; b=FOMZtCgB11Nybuu6jzucmGlbrowW9iQtfrjTWXyb2pfwV7FiEk0HOjegPqB5JfWHas8Zsm I7DJacxCV4dfllH/3lQrcxXBRXlgG8owoC8zLmfBEgDnGcrEL1lP5KvzjQFYNhzq2TfsDC fFzgrnmX2BrjVCjhFbNoqR5Ys8dMbMg= Received: by mail-ej1-f41.google.com with SMTP id a640c23a62f3a-aab925654d9so112043666b.2 for ; Thu, 30 Jan 2025 00:15:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1738224910; x=1738829710; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=0Yd9VP1y+BPQkS13xsK2KcWh5RNg6hbyGkYuynFoiXU=; b=ZtLSxnv1LMKsAPnfbrg25CmCLk1Klhr5H0nMYaiQVjive+s8ybt1WIoas3SvvAAe8n xN6F2FhVxduJJY3tPc0qeJthPtKCdZNnJH9+XHbpO4REapjFG6uCl4y/U+u4QZiL6cPQ SdtEp1b88gXRnJ8UeD7qo9qtZodNYfkK0Ig9xQkeShi7HJHllfzg3TE3xnlGeikHgX7z iaPkSTJalsriKCPJ26gQ0a1/c3+G4hMkK73RW9Q8lre7F0UKEbFISkg9lMV/LxKe+1RL SKRSzGoZkMQymVtxB63lppG3wFk2k7qUBiZ2ILe/IpsDyHmMbkrxL/P9KbFqWSOzbRDq eppw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738224910; x=1738829710; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=0Yd9VP1y+BPQkS13xsK2KcWh5RNg6hbyGkYuynFoiXU=; b=UXuGpg/QQIOBVymLAJmP5Xfz09hu/J3iwRw0VYReYm3qCCl8vH1eA9utFkpmtdNxJb gJ5MKN5soaLJTFJTv1vKEe7YBiO3Fhvec94/2y314z64+LozEl+ftc7f9FKX8mMJlyVu vM4588AsOiL0rqeY3yM58Tmuwd87GyuymROQXXIXnBIAF5b8YG5PS6pZgVnQvA9xbWah 6Sp99hoV7FVUoAM+XSw2LefiUsCvOtJZ88HR+SjN1CHDCW4tND31VZ/Vv3E1HyxCECKY JAcqPIoFVo41QcsUTECwaE5vxhTYCHeHhyre6gGYMImi/RWuhms7MDQR2GSqPKpIvmHB 18hQ== X-Forwarded-Encrypted: i=1; AJvYcCUPqG39dt6KSCWEbABjMMqIJ5z2cHs5ql6JjMjSerglpIYZUyXtNOBMzoTm6v70u/2FMUgow3JLfA==@kvack.org X-Gm-Message-State: AOJu0YxpzWCJDunn7++3M+vpTQDpFB6tlogu0LGyFeWZMOJvdaVlZ+Sl OUhG6XnTuDBrTdJdGMROc1y2CQaFrRix02Gx4euyFUxBziY1kpt1Z8ZuiLNP1hk= X-Gm-Gg: ASbGncuICiCZHU3ToDgiIm+7y/z8Z3usA3ziVr7tg6B9J+K7domWplGx+kXMglqYhBN nk46je5ZbYlkzWNok24V+STFIts5VUaXau+3g2c8wcvVx9jeh5NGtyV4Z4T0RZuPNwcAOtbHE4H iP6CiWKFog4bcH3jXK73IQ69SS3zeSFA7QeSsIvCl5buGiqNfiaHPLcOOo4jEfrrhiaWTD1yz/Y bjDBQB2PlGtBkuzBJYu0ghx4VnXgxUsiNcm9BC5qH8V00Mt0MLyCaXgxM2/7bz8qG5MheKyzykV bpDGKw== X-Google-Smtp-Source: AGHT+IHYvWOfej6DnMLzp2Xiw9S+tkev5jMy3KwGkLNQuYfF/NRaZoyfB9k61+r7Ggik1KDW2aMMow== X-Received: by 2002:a17:906:6d8c:b0:ab6:d47a:9b20 with SMTP id a640c23a62f3a-ab6d47a9fc0mr492898866b.31.1738224909401; Thu, 30 Jan 2025 00:15:09 -0800 (PST) Received: from localhost ([193.86.92.181]) by smtp.gmail.com with UTF8SMTPSA id a640c23a62f3a-ab6e4a32253sm76696266b.152.2025.01.30.00.15.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 30 Jan 2025 00:15:09 -0800 (PST) Date: Thu, 30 Jan 2025 09:15:08 +0100 From: Michal Hocko To: Waiman Long Cc: Tejun Heo , Johannes Weiner , Michal =?iso-8859-1?Q?Koutn=FD?= , Jonathan Corbet , Roman Gushchin , Shakeel Butt , Muchun Song , Andrew Morton , linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-mm@kvack.org, linux-doc@vger.kernel.org, Peter Hunt Subject: Re: [RFC PATCH] mm, memcg: introduce memory.high.throttle Message-ID: References: <20250129191204.368199-1-longman@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250129191204.368199-1-longman@redhat.com> X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 4184F12000E X-Stat-Signature: feair95cjktja35adksmchqpkoooddhb X-Rspam-User: X-HE-Tag: 1738224911-817420 X-HE-Meta: U2FsdGVkX1/HxbM+KDZcGHr5wYJiD4Xf4XucfqCJoehCaYdAXUv6n1heygpMn2B02kI03E3kRd1g7O85rUUcZqckEyDeW/8dpXpRPSyESstjxKzaL7dBf9XddiTXGhQWoX8yKycFiOX+OZTL7gYk8ICcWs+NpAusR5MYFPqUGhhOTYprmwNlqXCaEuJaHIfgeZjTmgdWlrSt/lKRvuE+rwGv3HgA8MZQEG+3WuMG9TlY3pqxwq06gc2o8l/d/NJ8O3wdapkY74nLgShR8AJWmiADhFMW4wN9A//plyw3pxxNeqBEjTeQ2URuBINfDH3e27uy1rFXC9fWBgCqF7CCyOoEoYEwCARYl0gO0hxL/KzSoDBdo8pmrdDrxZMNuMCHq6Zta4MP/o1uucK8HzqJ0VQhFkHH7XsCP+JTH4S+nbohZnhwC2vr5/gIpbqQbW2HvzMWRKwUXTyFfpLqIHbGWOrTRxXhg8Fcd6v2B5NA1laFlhBK8/iw+vZTATZvsX4SWJJw0cbFowbzkt/jz46A2alNTyFMX85g0UxyOGKgZZwAiFZGArHR7DACerN1WJp8oHNh0uQvBgwiXbFcQJHZ/vPYJGrtHnH2WVDnCwzu3RCvNw3Trz6dVyccxkjVZQ4ve8CEpyGf2W5XY11Etah6PVhfKBRUkO/YtKC1mPfMAgPEUJpwxZhO4+z3oGRbxTLdCbpsLGqfroq4gPiginKOl2xG4/QKbVejzDwI8xa0mjoWb74CvaI0Hh7a7RhpXLzAMjujNy1XD1eXHHqDIcUAIfTSnBdiptHES8qYJYz3eD1/P1mSJO9dhkn8yq/0eA+Dvz1GoVM1pRgQGSyjeSbprxZQ+pwyxwr64HOu+qRLyzdmxoVitMB6dd9TAjow5T4enj6Xd0QVLTZbVkdfRt0HqnvznEDlOkUud3P0VCrFfCJ1y6D3GvpUaErPhSqr8fbnO2x2q0lL2XARnz/2QyF 81/6w4aR M3zdvYEG9E3KbSvZRWs7RKJnGgcuETRQe8fKIwaJsR7/AnSKQYzG2Jz/MBtCqyXl5CBF23aaZh9aDGJwygjAFA2h+4C14xQNBnEXViK+CD2BzdTeM+doxaYi6CxcolvMXfc6pSLAOw4hjwTf+hlIxEInF0YIhx81sltmrbCyyIGGxozoKQwOeOBGRdHcYI4i/EK6hvEMdyamoqI5BDPeBtgy5FRZZ6SC7gbZA+1YnUaR0NVcH4LicaMhdesQoH4k+hoXT9EVKh6rt45/PMDftYqQ6t7JWbe+uyE2pKHt8JgqmYi5Hil8fX6pX8/NoqhatQUWD X-Bogosity: Ham, tests=bogofilter, spamicity=0.000021, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Wed 29-01-25 14:12:04, Waiman Long wrote: > Since commit 0e4b01df8659 ("mm, memcg: throttle allocators when failing > reclaim over memory.high"), the amount of allocator throttling had > increased substantially. As a result, it could be difficult for a > misbehaving application that consumes increasing amount of memory from > being OOM-killed if memory.high is set. Instead, the application may > just be crawling along holding close to the allowed memory.high memory > for the current memory cgroup for a very long time especially those > that do a lot of memcg charging and uncharging operations. > > This behavior makes the upstream Kubernetes community hesitate to > use memory.high. Instead, they use only memory.max for memory control > similar to what is being done for cgroup v1 [1]. Why is this a problem for them? > To allow better control of the amount of throttling and hence the > speed that a misbehving task can be OOM killed, a new single-value > memory.high.throttle control file is now added. The allowable range > is 0-32. By default, it has a value of 0 which means maximum throttling > like before. Any non-zero positive value represents the corresponding > power of 2 reduction of throttling and makes OOM kills easier to happen. I do not like the interface to be honest. It exposes an implementation detail and casts it into a user API. If we ever need to change the way how the throttling is implemented this will stand in the way because there will be applications depending on a behavior they were carefuly tuned to. It is also not entirely sure how is this supposed to be used in practice? How do people what kind of value they should use? > System administrators can now use this parameter to determine how easy > they want OOM kills to happen for applications that tend to consume > a lot of memory without the need to run a special userspace memory > management tool to monitor memory consumption when memory.high is set. Why cannot they achieve the same with the existing events/metrics we already do provide? Most notably PSI which is properly accounted when a task is throttled due to memory.high throttling. -- Michal Hocko SUSE Labs