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 762E5C3DA49 for ; Tue, 16 Jul 2024 16:44:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CA1016B0089; Tue, 16 Jul 2024 12:44:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C508A6B008A; Tue, 16 Jul 2024 12:44:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B17CE6B008C; Tue, 16 Jul 2024 12:44:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 93A1F6B0089 for ; Tue, 16 Jul 2024 12:44:16 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 3828D81792 for ; Tue, 16 Jul 2024 16:44:16 +0000 (UTC) X-FDA: 82346188512.30.6A8F266 Received: from mail-pl1-f169.google.com (mail-pl1-f169.google.com [209.85.214.169]) by imf21.hostedemail.com (Postfix) with ESMTP id 55C3C1C0026 for ; Tue, 16 Jul 2024 16:44:14 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="jLkMN5J/"; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=pass (imf21.hostedemail.com: domain of htejun@gmail.com designates 209.85.214.169 as permitted sender) smtp.mailfrom=htejun@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1721148211; h=from:from:sender: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=o+CNye71moJTbH6lgtmPaTmt3WinfyunEpCx02RJRQ0=; b=V7uolx8fMwiOSDFW6TZvi5EUiWPy2xaabH32g8ZVYGjEMkELQmYRcIheh92twV7vtHTGBP JKewjF8UfQ2dk/z2JorGHCDYKesorrhtSaq6HlkTCo1JbF6EtTo+RPx7P1cLEwoEm506xM 4ne83IW1uVm+8YRSGwtFrp5MreIuXE0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721148211; a=rsa-sha256; cv=none; b=Sap73+KbeiaZm6aDpWu6m+2Vu5/Tcem/bkRFcgiNXE3n7f1C0brDJJe/ZUDl2IAUaMMzi9 hA9A/RAve6eyp95BvDkMTHUpcmUys/hnWQl3e3zX3qfzObiooYWUwn5CqbH6JxAa3Rg0N/ QbwHRBNlZy4ypY7FYyAS7K7rh+rzjgQ= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="jLkMN5J/"; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=pass (imf21.hostedemail.com: domain of htejun@gmail.com designates 209.85.214.169 as permitted sender) smtp.mailfrom=htejun@gmail.com Received: by mail-pl1-f169.google.com with SMTP id d9443c01a7336-1fb05b0be01so40506505ad.2 for ; Tue, 16 Jul 2024 09:44:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1721148253; x=1721753053; darn=kvack.org; 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=o+CNye71moJTbH6lgtmPaTmt3WinfyunEpCx02RJRQ0=; b=jLkMN5J/aebWnePVUPDLg24EN1hm2eg6zHg+Tf4su14B9UDJ+7LHrnfTt7xVqRAODT UX099zdZRIFhVnkE5DoY/mY3t23JvBEVy22Gv9xGIgbTSNtTpIk4MCCpFTBGquhIOAp1 Jb4V2hqlrvAyxoaYh9IqqISAFQbUbn/tpeX5mH2kvZedhZaStriVDkucb6zPMo9Mn8UD zBzf+MSlmRdbjV6UlJ6yciAmzsips2Qne3xiukRzEqz0pAmCOGq61cRAHPn1zyO98RTT gNtURr0jYZxQzJG2H4kq6BFuH7dRhEIaFPr5/QTrGew7LraSzLuL7NajYC8d21FKM0kt NgEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721148253; x=1721753053; 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=o+CNye71moJTbH6lgtmPaTmt3WinfyunEpCx02RJRQ0=; b=WTaUXwv0QBaP87oJhQ0lb8VLjY4/u1WwKfOnYLXlebDhryZjaJqGgxZ5W2wb+L4Pcr lmdAYwyMip7nhaaeTwIYW0+bBz693hOrMWh2bqqolFSmfypOC1Ue1BsAAVIdHRJrPN2V T3WqqSP50czvK//PGspePOxpB6Zgb+gwpvPbg1imFcLDsGOF9dkKVcAuvp+cHHLYb4nb /R2sSgtPrDOdT2kFgSp7vxFXkaStcpuaWeg809eZ06t6rPrz4aRJhva+RIf4+AZtW65Q T8OernrCZu2o3WbTguNP7IsoM9rtrKoubQ3n+pdZd0LwiTnARdL0EqRKap6y/4TAjbu/ Aybw== X-Forwarded-Encrypted: i=1; AJvYcCUMIejQTtQEUWR5LBhlIF1JGVTtgS1oY6Z3L+A35RlaP0o7EglXnHc1wuFd498pUykqzKWGyK8kbgwj9KO6GmXDFlI= X-Gm-Message-State: AOJu0Yx/CKWfSPQ0is5xuVQRMGhnoHPH16qypuXNHJM7PwPYgemhjk8h FmdDa41VZSxscZdkP8OzeecMKpD1bjILbLbaku/SULQcAzZr4Sb5 X-Google-Smtp-Source: AGHT+IFJTbkJ4XB7m4WaS7/c2xk1R7iNNXoVb9NqqFwlW+JzGTrtgh//VsiTNurobqayni9p4YzZYA== X-Received: by 2002:a17:902:d50b:b0:1fb:7f2c:5644 with SMTP id d9443c01a7336-1fc3d93bb64mr22987525ad.31.1721148252947; Tue, 16 Jul 2024 09:44:12 -0700 (PDT) Received: from localhost (dhcp-141-239-149-160.hawaiiantel.net. [141.239.149.160]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-1fc0bc27378sm60382695ad.158.2024.07.16.09.44.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Jul 2024 09:44:12 -0700 (PDT) Date: Tue, 16 Jul 2024 06:44:11 -1000 From: Tejun Heo To: Michal Hocko Cc: David Finkel , Muchun Song , Andrew Morton , core-services@vimeo.com, Jonathan Corbet , Roman Gushchin , Shakeel Butt , Shuah Khan , Johannes Weiner , Zefan Li , cgroups@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org Subject: Re: [PATCH] mm, memcg: cg2 memory{.swap,}.peak write handlers Message-ID: References: <20240715203625.1462309-1-davidf@vimeo.com> <20240715203625.1462309-2-davidf@vimeo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 55C3C1C0026 X-Stat-Signature: cm59pasq4r8kosgguih8e1hoef4a1yy7 X-Rspam-User: X-HE-Tag: 1721148254-147594 X-HE-Meta: U2FsdGVkX1+8PIqpecxjIy8FaY7Yt7arQ8G7aYIsQGUCEXJHUlAIMYYEsEnNOYoCDjjT0ibp/W+eYLQcoXCsomrhJmG5CneJPZzdg7QHopAroEBr/ePmJ29E0cht1d4CDkNmcdG9plc49vJ+E7zTWO67cK7EfPZc5UFn6/pWduKps9NX9NnVkr+9VfQBvp4G6k3FXMLeqWhsGd/d0H8Zf15+kUcQy1QBOhgSZ0y6G1BeHuEyUjD3TvjNluCaJxd7g2RjVvREiuuHQRuHOTLu9tv4RI2JUX2JBkmZIThLgr5N7sLQfWKhSgrDpBbihyhFMqF9foVjGqjMEHV1znzwSbEBR/KZ6Kzq/YxpUDis9xX0Eebn6090QzrcQ+mYyeCmBlaozT72kmh9j/dDX1J+pmsg8LTvZaM1hWrs3VSwvlQCL2/OVGeP4D+T7ycwmE4+Pv65A158TrD3xSvK8CyOUKSpl3z8nmePChtfWR+3hGS4Le3BKstSCpwD9f3ben1iom9W480i7t6oIZdcTh1Lv+JquuKKNJMua6k4lWSh9KdW7olF7pKH8niZgK7XOY/12xzM57lZDws69lfXJ+GrzTIZpCzNnVi9CsXGCW2CPnkG3wRqxCE9H5G4b2J+pue23+euebO7YbNQQ2IotkSV/WH7lXrRqSKoSmOiTkhR7gJjYo0bA5L7qtYZ/xouZD5pHqaA31EJrhu4VjaAcsBeyUF8n74631Gxlt1AMMC+qo8SEYW66m2MSPnddFOi13XbTN79j1a6ToGfGyl9YGjH1Pw/yfU/RyPo7ZMCzVaRJp05w2bpFjUs98AgCdJ0SZjtNNJk1JUseovX7aAdLe9eMoAt4Q3eWoq52YiHjeizj2bpLqxN2TO5Rs/tJ0artAKFoMIR+QVXbVX+LvZk8fEeEW2bh4ggbAZPrlZ0qr29VbAXVffLpgBDqfYMIgPw/S7Z0FuGyKbUsfmyBeIb9/X G+eGYvbI npwID6iuveBQo2Ua1DUq1ZAIOW5d7BAzyqxeoGIzGsO/wN6QbSCZg1OlMDrQsozMbGhIMeym8XbzFcvlFxjldFsnJnfd7S4u7rx1UH6lqB5RLFrGq2O09RDjxBcShOlns3MFvzMpLov0eyeNbbI/9FBpt1080BB/66V+Cdnt2VTgstrXQkr2sMP3BkmFnCFj7yXDNAzfwOAQWvCYr9dm0llqCcUKGYEqwVVAspdJTcgwEGhAMwgE4Hh1hO0t82DqNoW0nFXCOT0A50sggoR5gQ0CHYgg1ao680wYx87qUTRwQ+Zx6BYdsVHGa5k4JTx5FlUK2EN25nt8srBSDKBF9+XXgwygAGg2TV627Btz6w7F0ZJkHvemWxQvoITVhf9wsOTJOWx+OL1XbjPAj3vh5c17U97EfXMjRoZPn83kCU/vF0i012vZs76Q3ePc7zh7kvw5d 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: Hello, On Tue, Jul 16, 2024 at 03:48:17PM +0200, Michal Hocko wrote: ... > > This behavior is particularly useful for work scheduling systems that > > need to track memory usage of worker processes/cgroups per-work-item. > > Since memory can't be squeezed like CPU can (the OOM-killer has > > opinions), these systems need to track the peak memory usage to compute > > system/container fullness when binpacking workitems. Swap still has bad reps but there's nothing drastically worse about it than page cache. ie. If you're under memory pressure, you get thrashing one way or another. If there's no swap, the system is just memlocking anon memory even when they are a lot colder than page cache, so I'm skeptical that no swap + mostly anon + kernel OOM kills is a good strategy in general especially given that the system behavior is not very predictable under OOM conditions. > As mentioned down the email thread, I consider usefulness of peak value > rather limited. It is misleading when memory is reclaimed. But > fundamentally I do not oppose to unifying the write behavior to reset > values. The removal of resets was intentional. The problem was that it wasn't clear who owned those counters and there's no way of telling who reset what when. It was easy to accidentally end up with multiple entities that think they can get timed measurement by resetting. So, in general, I don't think this is a great idea. There are shortcomings to how memory.peak behaves in that its meaningfulness quickly declines over time. This is expected and the rationale behind adding memory.peak, IIRC, was that it was difficult to tell the memory usage of a short-lived cgroup. If we want to allow peak measurement of time periods, I wonder whether we could do something similar to pressure triggers - ie. let users register watchers so that each user can define their own watch periods. This is more involved but more useful and less error-inducing than adding reset to a single counter. Johannes, what do you think? Thanks. -- tejun