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 D26C3C0218A for ; Thu, 30 Jan 2025 15:05:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 43F02280292; Thu, 30 Jan 2025 10:05:43 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3EF56280290; Thu, 30 Jan 2025 10:05:43 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2B615280292; Thu, 30 Jan 2025 10:05:43 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 0C7E9280290 for ; Thu, 30 Jan 2025 10:05:43 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id A2D8480FBA for ; Thu, 30 Jan 2025 15:05:42 +0000 (UTC) X-FDA: 83064442524.28.FC2AC90 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf29.hostedemail.com (Postfix) with ESMTP id E109212001D for ; Thu, 30 Jan 2025 15:05:39 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=LiAYEW4V; spf=pass (imf29.hostedemail.com: domain of llong@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=llong@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738249540; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=UAngit6M03LgRRaR1K5FI0V6z65Vw9FPDcpq2Hs9JbE=; b=qwVuC2mZSwlagXHcz+UeqghSs08viXuMSxLUYokcF+N/EkmZELDflvFhygTlN2UT1VKKvt oyADCVzinRyr2WnKy6hUgSIUaB6i8CszoYBsQTCHEZS0lFSyLHJTh35FwQ4rfF952AImhT UO1wO57I/wvcATcTsD2cv5jg2yecnmA= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=LiAYEW4V; spf=pass (imf29.hostedemail.com: domain of llong@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=llong@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738249540; a=rsa-sha256; cv=none; b=OPDu2cV0WPiRKKnI0852VWCiup0smbMzhki6CjwcboxMIkW+QFrY1yHPXoyruoM7veW/93 wbfK3I30PG/HNEhAzP7K5lTGBF3iYV+hRAwMHqZKyemt4NiQwu68qkOu3bUcJzEI2trgCj 2ARPUGjqnfOCnCfGG9EQWyZcuh6kyBk= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1738249538; h=from:from: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=UAngit6M03LgRRaR1K5FI0V6z65Vw9FPDcpq2Hs9JbE=; b=LiAYEW4VmBkug+NMtnGoiF1dp7qBiAz0r1vBOKPRTCGRQZVeJQE8nD30TNKOyTsH9hR6I5 gK5sCHjsa3M3dBsUH+/sKcfEbl3JKCKbcOwNB+19taNlLJFJcDgkROIsVZfUitYIL58q6X Wxg2twrVOBvs8Tw35VDFIhgCdLtMlvY= Received: from mail-qv1-f70.google.com (mail-qv1-f70.google.com [209.85.219.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-481-vBDEZh75OLGjHCqOUzQQzg-1; Thu, 30 Jan 2025 10:05:37 -0500 X-MC-Unique: vBDEZh75OLGjHCqOUzQQzg-1 X-Mimecast-MFC-AGG-ID: vBDEZh75OLGjHCqOUzQQzg Received: by mail-qv1-f70.google.com with SMTP id 6a1803df08f44-6d8f4a0df93so23961786d6.1 for ; Thu, 30 Jan 2025 07:05:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738249537; x=1738854337; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:user-agent:mime-version:date:message-id:from :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=UAngit6M03LgRRaR1K5FI0V6z65Vw9FPDcpq2Hs9JbE=; b=Xuxp7Sor451WoFtTeTjtRKdloA1SKVJaV/jDVwuuKTIDbkji/tt8VT0Px/Z/Rp8rar ypy4BByjS9EhnFN4Ib4xPhDuHeQVMV2NaQchDirLP6e8+Q4PEG8ciVp/IHvfjfoUz0TY uHopbJwVApjWUmDJUdXF8AXX0Cosl3zRTjfcbL9C94II6G5z1Z7uqM5bmjOC48vzD5SU zSEnRPVsR80dkdFUG7G2We5WPtALrdFj3bm5hdETpVq1b0qp1KkJNqp+OdnDvbD84isa cJ9NKXgKNEq72x53XmoeTyuMIJACImDGZo8sDRGa5wxxYD+5mEmW3i28U7JacMRFbe+J SXuA== X-Forwarded-Encrypted: i=1; AJvYcCUche7hJuq4QKnoLkDi+nl7hwsXdkdJK2GuH+xopCPnSzSaGF/kEnOuikehr/XzysnZ6ysUIwTErg==@kvack.org X-Gm-Message-State: AOJu0YzHxUWRSOnwipIJ1pg5OTb2oVVCtqGnNKnn6lOApIQ3fBZRh/fo UuO8qtefvL8nQ3VG1s4ufDIdEOe15eNvyYeteRMt9gXeMw6sL/SfScMA5PWBUE6f6f5+/8RYzCv S96a7255Z5nFqob69Txu65xnX0iJxUUXEPQaXh1l/RCEckioU X-Gm-Gg: ASbGnctv58Exw0KlAlUNuYI9KIYcGqc/SqKxY4h5yf0ts0qnHEXA6OwvCPpOKisFhWk wfRdqbrGwyfJ5Zet5fVoSN0fz7jAkJdW/sYHZG9hr+N9QyX57RyQp3w6FD2sd3wT8io3wY+Mc9+ ISQZ6lkEAt1U45U04weO8+NoIKNjwauIk+DWLMZRfZhX21Mp0XgvZxY5PFyWsapJV4+s+Cw4Wx9 Rc3+OFfnHkhYu9b3nJZL1s1+GApI/jf2H9iV1emx1ivDB84RRyV4EP8GD2GWmAFoo592B0R3UgU hMfBBP8kK5Z8XO/CcrCyJvtjG5FbzZDqfNA+J+nOfEIMBhEb0zM= X-Received: by 2002:a05:6214:d48:b0:6d4:dae:6250 with SMTP id 6a1803df08f44-6e243c67537mr126629426d6.34.1738249536671; Thu, 30 Jan 2025 07:05:36 -0800 (PST) X-Google-Smtp-Source: AGHT+IGUK7lLnq0YpD0cZmVruuYg19C46zZhFDKnof0uqIEU4K98pvy7EmVxD4asUaHatzWO9jD7dg== X-Received: by 2002:a05:6214:d48:b0:6d4:dae:6250 with SMTP id 6a1803df08f44-6e243c67537mr126628996d6.34.1738249536237; Thu, 30 Jan 2025 07:05:36 -0800 (PST) Received: from ?IPV6:2601:408:c101:1d00:6621:a07c:fed4:cbba? ([2601:408:c101:1d00:6621:a07c:fed4:cbba]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6e2548357f9sm7038796d6.63.2025.01.30.07.05.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 30 Jan 2025 07:05:35 -0800 (PST) From: Waiman Long X-Google-Original-From: Waiman Long Message-ID: <211b394b-3b9a-4872-8c07-b185386487d3@redhat.com> Date: Thu, 30 Jan 2025 10:05:34 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH] mm, memcg: introduce memory.high.throttle To: Michal Hocko Cc: Tejun Heo , Johannes Weiner , =?UTF-8?Q?Michal_Koutn=C3=BD?= , 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 References: <20250129191204.368199-1-longman@redhat.com> In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: vv-xBqU7XTFrTK6iIyCMEHOQj2DriSE2S2A3lzu0bUA_1738249537 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: E109212001D X-Stat-Signature: dftjmtyzwnhu3ihomf6u5ds3nx1esn14 X-Rspam-User: X-HE-Tag: 1738249539-10175 X-HE-Meta: U2FsdGVkX1/0YQXR135DZCNBILyv+qtnd3rohM2G4yggUvGRBDVPr2qeYCLjNC7vqId1iCdCs5eVqJV8WrXESOR/C3kNE/hk1h/eNbaoLkq0xhhYisx5afSvBAXDU2nvD/2uTLXukYVrHH9Aji8OND7eX0xXmfWb5cjhSdsxdmSpKk5u4zjEIpHwGiWChqt8riO12/xgiKmwoMfCI/IZ/ysfwmA8tJtFCGZgsEjvaukEspeTS9Q2C8XG5uu1uxHYlFm9zenHoTqKTORom7B2xPi2kdThZSAITLjIZC5S1wmTqy3pASz8CK+nIdPi53RztB+zKiiEhA16zzK2Ey9fqBNC7o90HP8aOb2ZP4QA6NVG+rHbBiEfxoPSZcq/wLpFmL1WjSpNxsv7sBIStCdsAcTbBQ1dC7Aiv28tH+yQQ/zM/dfUhX/Pw8N/ULupgkcbkZgc8cBc1AmTXczM348IqnZDGLCi9AGAWphNeuozfo5vJMqWp7UtFUr9mzOABlGnyRqHOg3QGMjFRxZJmtxiAmPLiZbTO+T3rAe0Gi9xngh8VzAnxhIWwpy0BaET5sYlsDlYlL38AvmrhBgYjaW3Ra0B/LB0wrrPKyl9pSMKQ07nTBI7eKpbDaIxX7fK47NYvBDtbgsv33FpoZkuFYNTF4rXORcAjsPuQXuO5qtmep6Cw9b/7UwqUuOGrLXhFFdYgsVc6r46BjiMA1E8fOGC2TyJ73mPvOCu2W6iik4Oe9rB/hqUrDkCD0uNaUXqJqF5T21JvMtmlB2GPID7P6H4Qi3Uz5w675eKycA4AUG/Aur7A9a0UP+r0g05picd7gtvPMyKCruLheLcmNivcOsmBU/bMWBrL1Vw1miM7cKIBJKkdYdKu5r8UIQ/rQtSZ76TQEF2sscw1lX8oni8VBreDRW6DM0RVQNACJDJtPvE23wIl6D8ku0TJ2PZvzXXRAxVfv6+pbrf8RWq+Q3pfVI cnusVNbF ABt+ZLobqd0Kzt22OFEt01KBpwsVnVxRoElA9wu8t2plKzrVJTkuvvv+MHVTuAj5DFRQp/zjLoE93aBMGyr1fs5bE6T0f2lFjkRk7cXsiV51oLAcHp7kpHiAPZZLCzoiXmk9N2+p06wbZDdqq5BQCx/jNUJ8WXfKryLpuhOU28JoJj5jIHSSgjB185EjCR4mBXC+zBOsSrajOt8v62/Acw+Vgs/EWOvxY9eTkIuHIUXbw4BbivU2+Xn8IwZ3+O2DXZV0xmIHRupb0+GkkEWn5DczqHU2FGCbITwdS10WOywBDjMjBd+4Z3bbWQSumqxUAZErCerzMfzoB+ouv7WOB204eptHC/R5czeR/HC3I02vf8hza/V58hKMdO3L1/elcU5qOkg+OVq+5gj4AAqKo91K2ZCvU1DWoJldEReCflLzC3PE= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000101, 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 1/30/25 3:15 AM, Michal Hocko wrote: > 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? My understanding is that a mishaving container will hold up memory.high amount of memory for a long time instead of getting OOM killed sooner and be more productively used elsewhere. > >> 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? Yes, I agree that a user may need to run some trial runs to find a proper value. Perhaps a simpler binary interface of "off" and "on" may be easier to understand and 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. 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. Cheers, Longman