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 DE96AC3DA59 for ; Tue, 16 Jul 2024 13:19:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5BABF6B00A2; Tue, 16 Jul 2024 09:19:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 544716B00A7; Tue, 16 Jul 2024 09:19:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3BE546B00AB; Tue, 16 Jul 2024 09:19:34 -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 1712D6B00A2 for ; Tue, 16 Jul 2024 09:19:34 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id A912014177D for ; Tue, 16 Jul 2024 13:19:33 +0000 (UTC) X-FDA: 82345672626.12.89391E6 Received: from mail-lf1-f48.google.com (mail-lf1-f48.google.com [209.85.167.48]) by imf22.hostedemail.com (Postfix) with ESMTP id 917DFC0023 for ; Tue, 16 Jul 2024 13:19:31 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b="GNlMr/ya"; spf=pass (imf22.hostedemail.com: domain of mhocko@suse.com designates 209.85.167.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=1721135952; 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=TAlKCocTKV2Z8OTI/zDyKU1Nj0a/ekaC0DzlUNA8/NA=; b=j0bMQOXYP+zOcgl7ZO+903e7CGB8DoOT19U5YYuXLszBJXcCDMghZIKdarhgUmb93gZ99t BZw+/5JarsohazgYVL8GwIl1VFt6pxPvAgQyOgobDJJE9Pyzl3Ciix3xmIdvmyVi6+kmWe swHRW8G9wcX9SeEhlUniDm2mFCEKBkM= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b="GNlMr/ya"; spf=pass (imf22.hostedemail.com: domain of mhocko@suse.com designates 209.85.167.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=1721135952; a=rsa-sha256; cv=none; b=EhjePZMEJ00csi+2PJnp8wBd+0qnjDMG/PV1RiHfLW/hrrD8Hzn+y1xAOnI7ClysVstxd7 omCpZPhV2F4/JFL2v6rGQwo/Dr33TVc3r9K6EvbW0PK2jZQUIRfBb3t8FV2VKnbzKH77Eh N8eYrKMCKvs0vUUSQrUX/K0R8ryM6dM= Received: by mail-lf1-f48.google.com with SMTP id 2adb3069b0e04-52e98087e32so6601347e87.2 for ; Tue, 16 Jul 2024 06:19:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1721135969; x=1721740769; darn=kvack.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=TAlKCocTKV2Z8OTI/zDyKU1Nj0a/ekaC0DzlUNA8/NA=; b=GNlMr/yaYPyqVXcAdSCiyoMka7PvO7vzciJPq/jdkGv+t6Zv1MW6vaZvh6Aqri6p3N U7X+tTqv+a2vECGgogPKMU6WdTCz5n2ifzH9yirTbc7xa7FSYFpS9VlyLjolaI497Row NcUISK2kPS7sGF0663gN3+dpTqf8dWXAobzRDBWWlXTAMv67zCzDXkdJv4PqWhasTe/Q y7v0wxmmwSiM3byPbveiVRqNTmrhqYlKwBXQPr3X4BtOiQaTRjnuQEosyutu/E6BlNAd jGih0UoxGAQMpyifenprSX92mYCJpfc7e80zL+hrAC4tXocgMNCWD0qEhvxGTX2jyRXG QNzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721135969; x=1721740769; h=in-reply-to:content-transfer-encoding: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=TAlKCocTKV2Z8OTI/zDyKU1Nj0a/ekaC0DzlUNA8/NA=; b=RXIKSLHB+/WHTz/gtGeiCTPNy6uaTrScZkzh3RQaQvT7TXBWO4l/q3lYMhYVKCT9f+ P1mChmDb3ywBTXV9BYJalSKiK+Vz263GeKkPSa+Gg2ZztW4a371YOvoTsqHa+dFmGQnz CktYfbB8YvL7CZbyQe4rKF6wMeQjB5Ff89b5ZFl/6eMAEDe8N+w5PYac2OxkEAuDrkpe cRbi+IKsOtIaqYnMVJycbuC4o2AzsWJs9gSTa98934uYo4/bU/O6phuNpVEftBNE1eDa f/1yqPm7zhK+hNIdVbe0YxP0CM7kq6QuyfXA8j1o1gTS9MKRShHQnpkfSSYN1e6yR2q1 RAmw== X-Forwarded-Encrypted: i=1; AJvYcCVFgSuYwGFVH/jQ8JnwIG7unYLqa0m+RN0ldRrf7w2mJ7r3Cs14yqwGqJo/jFCgBezID6Ik+TojmOwi0IHc5baAGAg= X-Gm-Message-State: AOJu0YzqTdJqdrmcvLaYFhuPEETSBS/OudGJwnq/4jMxtHLJ9dQNEgUF AUG+mDpW5mxyFlbXs0iGS5rwRTJvffquAanEiQEFBBvUn56iUyypmWTNnPYBqRE= X-Google-Smtp-Source: AGHT+IGZhu210XhKfrl+D1o9RMwwEuk7GJineTGDspE4fOHXEfuk0VNWxNHYri5ev4eeWcldkYD7VQ== X-Received: by 2002:a05:6512:23aa:b0:52d:b1e4:b337 with SMTP id 2adb3069b0e04-52edef1e04bmr1616823e87.21.1721135969582; Tue, 16 Jul 2024 06:19:29 -0700 (PDT) Received: from localhost (109-81-86-75.rct.o2.cz. [109.81.86.75]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-59b255275ccsm4956445a12.49.2024.07.16.06.19.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Jul 2024 06:19:29 -0700 (PDT) Date: Tue, 16 Jul 2024 15:19:28 +0200 From: Michal Hocko To: David Finkel Cc: Muchun Song , Andrew Morton , core-services@vimeo.com, Jonathan Corbet , Roman Gushchin , Shuah Khan , Johannes Weiner , Tejun Heo , Zefan Li , cgroups@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, Shakeel Butt 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 917DFC0023 X-Stat-Signature: 3nd1p1ytk81w1ibbh877nmwf51tuxixj X-Rspam-User: X-HE-Tag: 1721135971-815642 X-HE-Meta: U2FsdGVkX19LMXnCIRAtq0iWI4DT42ZpDBY9BarC4eIfUbo8fD/fh17o6LXEZYqnKYXukXbbR8SOhMyUaze0civO2AdG8fU1uhoE+cPBMZju+8hRIyhKEM7IFprrr5L8eW8aGc2ihPxvXMPCP9K4vsRHW8VyL0fbza/kbdW/8ZY/7R9OP6azRXMtwTzElSys2MD7uQfe+Qaqdd7BxDGDdlryGQeXkM0I1OZkk4xNzOKa+gnA4wmQl+zB/Wg6NZxnGm29rQNcPwi5XeEjHlypHh3oEiPEcH8D5EqjnmUWptDqlnWa6YAoE1e1v3R1OQ77M00qKpA3/+tSsBV/zlRe/H+zQosVGtMDQXxLSLez4GNxQxYdbOth1CXQlvUlDgVigOu18wiA7ZTzjl5uA6OGhb9MzX58qKrbfVFr1pR7dDCIrIVeUL98E2dE+w8jVWVO2uk9S6brej5HBBfgEUJveuP7ZTQSKrSOUA4inlRtyhjO3WKREk+kz0gKTmF5XdPS9GKFxxZduek0qk9VRnSXOFo+HNiUE2aASQQ5c8NZb8gIpUFikK1TH1FRmaDTturkXkD2rmDLkp0ShamsGk+hN0LADpeUA8WxoLXXPdz/+8cwUP5qKDU3qRGp0yQH7//4zvD/pIpuURQifF8LDqo9RzgaNKC2WprdMca72sCdJrnu16GEQPrgvtG97CcWEWeeDqyHSQ3d3f9wzLrNpjyWBH+ZyoAptIb6MPGWutAvuADQoEzlTqU9JH2X3FBmOHaFbp7S8SWf4zPWXoM+2b3FS1V9oAWZtoT1lbaX5jX8EGWxnDOJltNMvp+QMo7ITypazqyMOhhwHi+BZoUYw9YUXzmEN6bfLOtsIaHZ/FANuaTXIDhUK2pAjelQ1IbvHoXiv/KDXxD9zMXGQzKn4/OS7jTVBUoQTJo7E6VH9uyd08gKQkpMXbwr/vL5eojRcTknsXpk9Zpz1Dd/O/Uj5KN A/dlr2xG WYFWuF6yd3FKWxSYacsXU+ibBnBJ0Ph3xnGqhc7CBWIVYQxio+hLX9kjfdmxIbXXYdgCsD/B8pFbNC/Wo/uuyuGVvQSJyxba0kTIzW1Laxov5xuJkck2od1tZ8PE3+5q43+YVgRsdAUwVzGJw3QlUCHj5fRyDe+oNivobzt8/uyKSj/6Tw2WXTENROmZHXg0kSExc1x0AtHdB+AkVp4aQ83rcDFlZ/4KPMHjXgD2Ow/OYp/4f2ij4c4wweacME26TpZuBa2lDz7GTuS3Fn7v+lE6IP+6ZLvkcA5p8WDMeQQceiE2dCeUFYCOAt6XzChGAqJjY4mhj3ed3/oTSzLHqbHXWE1gXtsdf93G30BD6ByEMtR9Nsg35Ti6AshunnDoAMGygirW5ijeubn8= 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 Tue 16-07-24 08:47:59, David Finkel wrote: > On Tue, Jul 16, 2024 at 3:20 AM Michal Hocko wrote: > > > > On Mon 15-07-24 16:46:36, David Finkel wrote: > > > > On Mon, Jul 15, 2024 at 4:38 PM David Finkel wrote: > > > > > > > > > > Other mechanisms for querying the peak memory usage of either a process > > > > > or v1 memory cgroup allow for resetting the high watermark. Restore > > > > > parity with those mechanisms. > > > > > > > > > > For example: > > > > > - Any write to memory.max_usage_in_bytes in a cgroup v1 mount resets > > > > > the high watermark. > > > > > - writing "5" to the clear_refs pseudo-file in a processes's proc > > > > > directory resets the peak RSS. > > > > > > > > > > This change copies the cgroup v1 behavior so any write to the > > > > > memory.peak and memory.swap.peak pseudo-files reset the high watermark > > > > > to the current usage. > > > > > > > > > > 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), > > > > I do not understand the OOM-killer reference here. Why does it matter? > > Could you explain please? > > Sure, we're attempting to bin-packing work based on past items of the same type. > With CPU, we can provision for the mean CPU-time per-wall-time to get > a lose "cores" > concept that we use for binpacking. With CPU, if we end up with a bit > of contention, > everything just gets a bit slower while the schedule arbitrates among cgroups. > > However, with memory, you only have so much physical memory for the outer memcg. > If we pack things too tightly on memory, the OOM-killer is going to kill > something to free up memory. In some cases that's fine, but provisioning for the > peak memory for that "type" of work-item mostly avoids this issue. It is still not clear to me how the memory reclaim falls into that. Are your workloads mostly unreclaimable (e.g. anon mostly consumers without any swap)? Why I am asking? Well, if the workload's memory is reclaimable then the peak memory consumption is largely misleading because an unknown portion of that memory consumption is hidden by the reclaimed portion of it. This is not really specific to the write handlers to reset the value though so I do not want to digress this patch too much. I do not have objections to the patch itself. Clarifying the usecase with your followup here would be nice. Thanks for the clarification! -- Michal Hocko SUSE Labs