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 14E0CC0218A for ; Thu, 30 Jan 2025 17:46:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9F6DE2802AF; Thu, 30 Jan 2025 12:46:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 97FB62802AD; Thu, 30 Jan 2025 12:46:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7F93E2802AF; Thu, 30 Jan 2025 12:46:52 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 603082802AD for ; Thu, 30 Jan 2025 12:46:52 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id ED9B94122D for ; Thu, 30 Jan 2025 17:46:51 +0000 (UTC) X-FDA: 83064848622.30.07DB394 Received: from mail-ed1-f48.google.com (mail-ed1-f48.google.com [209.85.208.48]) by imf21.hostedemail.com (Postfix) with ESMTP id DF2E91C0002 for ; Thu, 30 Jan 2025 17:46:49 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=Ba8nDxQa; spf=pass (imf21.hostedemail.com: domain of mhocko@suse.com designates 209.85.208.48 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=1738259210; 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=5snQbJ38VvBoZa24EBcVoHQPXCYbY/0kZ4L1ZVXjM+M=; b=gHERNYCTEz3OTv8KFxmljCDKrjl39seMvmy4xZ4H4FfF87YvL9uw9Capqzk4C4ZYUF1lqz obiuW9JSpORijXRw1BBxhoLHajZ3DOiQTdLrbNNs10jRBFMWY/5FKmdE/5OkzNeI2ljZKn p3I2MjN20hPA0SdJZvjN11xHvvKp6Wk= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=Ba8nDxQa; spf=pass (imf21.hostedemail.com: domain of mhocko@suse.com designates 209.85.208.48 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=1738259210; a=rsa-sha256; cv=none; b=tbhghEa58Ul/t+Ja6cgD1vm8zXQCZNSqOf9CXHrDd/Vv29Wfw07Tv8U77bZEBH0oY3wyCo pDszeupmTA2iNOjtgJm9+li6+Yrx0IqB2S9BzCIhaYGr1sI5VVkowbDwNwF1pBqvyP98iK 7Ju5j5QFtuRs54bDwMuGPwE4usPxH/k= Received: by mail-ed1-f48.google.com with SMTP id 4fb4d7f45d1cf-5d3bdccba49so1711161a12.1 for ; Thu, 30 Jan 2025 09:46:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1738259208; x=1738864008; 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=5snQbJ38VvBoZa24EBcVoHQPXCYbY/0kZ4L1ZVXjM+M=; b=Ba8nDxQaZqD933+2Ya/M10jCdQtRhvU96L8jaX7kMbd/BOW0hFj9dG6RErAkn0vxRT JoMNNZDAAiq2SyWe0zXVGqn5ZywVxEO7HWe0CQkrt8PMnAjTG2m6NBiMHYSaNOftdYMl VqfZobU46lmqjwLz26VBSX7utnaPAAb7cTYEnLivnVx7/Vn0Kx2xeFePYAZMsPtXJLGT Uuk5i31C/acnhbTbb4ffo5bTG9oq9Fa3b8NZHIh9AEspdXx7EXVxuCkhMkAGrEwAQw/X cBb5TiqRYXqqgsnGOcn+DrL10CT12UGWzEgwhT0OnNOjHSWBlDKAQrlEdbdfqQJGmoAv KwaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738259208; x=1738864008; 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=5snQbJ38VvBoZa24EBcVoHQPXCYbY/0kZ4L1ZVXjM+M=; b=Sb8nDGS8FxYITQSMO/J4DXlLCcR5VhQNvweG0x6Jl52BrI8D+4s4caapdSQnKC43y6 xscN5hbmfMggSkxtbA+WQjHxCSKLkoHs452VdbA2SchpnYCrww7SpwaiZnVjVwcbvaRd cwmuybP6grV5FuhxQxkUAC8tfO5wyNbF50uB7UrflPBVljIAxOdd5i44w1wkDF5fnbuQ eqxECFc+9KwDfTTgsqu6xhuk/+rAZuzo3EbXXYYnPGVlXA8g4FEvNlb/pd+q1+oKifT8 pcVyHXX02mdw7zMHAD+6ws5GSaFKjQHxNm8zNIB1AR/ueRZ3HcbbTQw0vVbebVRAAMl4 Ntog== X-Forwarded-Encrypted: i=1; AJvYcCXFdOO/JC24FhfXiNTop3+yVCJeIc0zdk+NEqgPbiEWe+kben9VAA5sJeYSMks4SQA1jobuM+9wyQ==@kvack.org X-Gm-Message-State: AOJu0Yx9oPlmaqEagDFZlaNzbGhAMnrONhCRsJDUea5WehhND8jPZabT 9mTa5c8gV2UTUaqOu2fJ3Pa0Tk14GUpxBsG/n2Zg/Yf1YRnQ0iISkLR2aRv5U0U= X-Gm-Gg: ASbGncurcMWVCgHxtOoNqD3j6YZRUEv7TOm3eEq1Z/gPuInDDjCkpJcvw0a4WXeYYZf 3BfxyOQg2FTPksHCjbYRnVTup2KMzfPA6XXTUYBIJ2dPhUZyMzcAvxYdEdTeZN4bnANX/OmoiIx K7UPGMU0lkfykpFh0Gh1Oi6ns6JBHIdjZni5NCg4Hoib0N8PIWZlqbchy6lt050fEloU+JQkkbY OyOoWEKwfo8xf13WhjSPZY51kzNrURkEyt7uderygaXskZGpNIGGK+Xrd7d6+MxwoBfXsyK3wQn sI4egv7AKzh3vgq2p0i1czZfkA== X-Google-Smtp-Source: AGHT+IECYjOfJz2tOjzTqFxLsspzu/nakrwmV49yfXfMxCTrHiIH5vR5VrgKigD70NLDeXJhSYb9BA== X-Received: by 2002:a17:907:9726:b0:aa6:b473:8500 with SMTP id a640c23a62f3a-ab6cfda4249mr845523666b.42.1738259208184; Thu, 30 Jan 2025 09:46:48 -0800 (PST) Received: from localhost (109-81-84-37.rct.o2.cz. [109.81.84.37]) by smtp.gmail.com with UTF8SMTPSA id a640c23a62f3a-ab6e47cf883sm154114966b.49.2025.01.30.09.46.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 30 Jan 2025 09:46:47 -0800 (PST) Date: Thu, 30 Jan 2025 18:46:46 +0100 From: Michal Hocko To: Waiman Long Cc: Roman Gushchin , Tejun Heo , Johannes Weiner , Michal =?iso-8859-1?Q?Koutn=FD?= , Jonathan Corbet , 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> <211b394b-3b9a-4872-8c07-b185386487d3@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: DF2E91C0002 X-Stat-Signature: xjtjxj11egmem148sca58z1zfybki65g X-Rspam-User: X-HE-Tag: 1738259209-244410 X-HE-Meta: U2FsdGVkX193X4r2KVI2hu0pP/GBiULuwEddwfvZaSNd5ZWVl3wwmfglExX3KZKhk9vC+M34cirDypg5OYUEyTGCcWC0q8m9psYJ6QJvdX9fFAeQKys91NPj6d6c/3AK2623V+jqg1Kr697sUf8/8xniBiAG7GyqjCL0H8sXh8G0qcbMqOmpsYn4EWy2WYnSoTKqkb+7+NOtybNh+n4VIPZDIneQdQ1IBJFYmY6CZVi8kSCWj60molpTwV1lMmjPhqYmG2DA0fR/OrxEzhVzhJwK19xU6dAkX2dW8LE9aibF+8ELLZcCG0TCOpeSFdD8RqY0tcL+EQ08DgtMgFIQ1jHNb6OoHSDciAm3zZ9YBVBgYhj9C+v6JO681jCBo4RS9Q/Xw6K1/+uH7IDB7OiS+CZJnWflUHWc8Reu6LQS7TpM4Fy9tN+CSqEuUARQHmxdXs9zbqYRANK9WTQjppyY3nS/AczLelPdXUMBPl6K2Vll9KM71FadrPZ5SK/V10uJNLp1M5zFDhAbZQnYKEEH9w9ZiPX/4/6oBL+tYDv7m7ouLxitncfmfQGWEjl2nVWts2a7UIPKYiNApzYcM7k7OU6GNPnxrqecA1Ef4c0UNCJJrsZY7wRNDZF9lnDyh0CI9dX2NFtYu1PnNzAPBP6tGRWSMORjnBUheAmgPXSaIJL2Z22YI+aX8k/P7Ah5aFsTzCiuY0Zh061m++cFKJMlxEkaG/C7tqQiPTAR1vkQxpmAYrR2RaSbnZVZ8xMsdb6RATLQ4Tw2Vsxo0grtiaz0DILXYCLTGIAead+Q6+stEx7CK0KKdj1yEYgVeplbrPohus7EkThe/G0rujXNELs/13xHfI0Q2vuiql3+Je4OxEkoAvgpB+tsJ3eEOqW8qYvlZ9sB1R1SRAC1MhCoPKGvyQ6969UDuxsWrqgM+C3ihFRzila1hOasUh2J15nd5yimhselxdxu/R87GU60rRx OEYBtGR1 quIA742CMKVTDrigNDMfuGNjRiGED1AGIJgTTYFTPVS4yrkvKamaQBysrNsWY59ofU9Jj0Dh+86P9YX7xXy9V4nfKZmLnxhCF6c3NWWWlGGeF6/r2lrtdNKYndAqctn8Tg99CDvHNA1/B2wAFNhvsmuyjbc8sgkhLqLIXpOa6cm+GIAe3fkR6VoRjOEFbne4Doqu30qQ2rG3s+XGkfSNDueFlfSI1dPi1L/pvZ9rXr2OnPLnwCv9NU2p+u0/GBwPjoiLSZFhVFvWj18qH/THo5uaSfS4FYNv38pIk+A7OrHt1kQP+dZH9BsXXuypHkr2gvFsm 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: List-Subscribe: List-Unsubscribe: On Thu 30-01-25 12:19:38, Waiman Long wrote: > On 1/30/25 12:05 PM, Roman Gushchin wrote: > > On Thu, Jan 30, 2025 at 10:05:34AM -0500, Waiman Long wrote: [...] > > > > 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. > > > That will require the use of a userspace management agent that looks for > > > these stalling conditions and make the kill, if necessary. There are > > > certainly users out there that want to get some benefit of using memory.high > > > like early memory reclaim without the trouble of handling these kind of > > > stalling conditions. Could you expand more on that? As long as the memory is reasonably reclaimable then the hard (max) limit is exactly what you need. If you want to implement oom policy in the userspace you have high limit to get notifications about the memory pressure. Why this is insufficient? > > So you basically want to force the workload into some sort of a proactive > > reclaim but without an artificial slow down? > > It makes some sense to me, but > > 1) Idk if it deserves a new API, because it can be relatively easy implemented > > in userspace by a daemon which monitors cgroups usage and reclaims the memory > > if necessarily. No kernel changes are needed. > > 2) If new API is introduced, I think it's better to introduce a new limit, > > e.g. memory.target, keeping memory.high semantics intact. > > Yes, you are right about that. Introducing a new "memory.target" without > disturbing the existing "memory.high" semantics will work for me too. I thought those usecases want to kill misbehaving containers rather than burning time trying to reclaim. I do not understand how will such a new limit help to achieve that. -- Michal Hocko SUSE Labs