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 184D6C3DA49 for ; Tue, 16 Jul 2024 13:48:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 77FBA6B0082; Tue, 16 Jul 2024 09:48:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 72F936B009F; Tue, 16 Jul 2024 09:48:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5F7596B00A2; Tue, 16 Jul 2024 09:48:23 -0400 (EDT) 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 419C56B009F for ; Tue, 16 Jul 2024 09:48:23 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 76366141720 for ; Tue, 16 Jul 2024 13:48:22 +0000 (UTC) X-FDA: 82345745244.30.704A544 Received: from mail-lf1-f44.google.com (mail-lf1-f44.google.com [209.85.167.44]) by imf26.hostedemail.com (Postfix) with ESMTP id 77EF814000C for ; Tue, 16 Jul 2024 13:48:20 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=WMfIMbSk; spf=pass (imf26.hostedemail.com: domain of mhocko@suse.com designates 209.85.167.44 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=1721137649; 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=KM8Ao0zGor69tQroBWIUZVg9uwOWjyC5j2aDW1h9Y7M=; b=T3weRriGPnP1jKjrjVIQ1u0s6QKoqhFy26FJ5ByxoGdt0+5Knw6yw4ERku5SLJZQwMSoqc oXmLjI+6+82w28dK4QGi/omzrvxrRRJ6oeUJLQ7gOn1SKiMWdevGbLfo5Oy9FEqwRAoBk9 JUM8lFTw1N1FTlptple3YDKyds8FBeo= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=WMfIMbSk; spf=pass (imf26.hostedemail.com: domain of mhocko@suse.com designates 209.85.167.44 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=1721137649; a=rsa-sha256; cv=none; b=GCHOz03KXaRHo8lUDm9N0J+GBHfMDrmPruYbMc7naGadvI9t8+S0Qo/t7558qYk41T/IM2 cOtDRpfsb/2IuvZwJtGydMNKZ7Ax7scuhORjV3bD8xV3/kt1lrkUoTZaixBmiwo5z5O0k+ XTZS3RFSQoi0WMAGUd+pDIFQ9UtpAco= Received: by mail-lf1-f44.google.com with SMTP id 2adb3069b0e04-52e94eaf5efso6856194e87.2 for ; Tue, 16 Jul 2024 06:48:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1721137698; x=1721742498; 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=KM8Ao0zGor69tQroBWIUZVg9uwOWjyC5j2aDW1h9Y7M=; b=WMfIMbSknEqGXmpTQhUZEiQbkY2QdPSvMqjSD0uX9tGFPXDkyD3/4Hv/fW7S2I1WAR uerGgkHtG4+mV4I0etifbfQGN/CVgHEPrzpa0Uxuu6nUQlVlSXE4VVqFv857YFufQXOJ DEX9a6qDKMuE9uTcFVVAnbDjaJ1lWk369P6f16BzxrPeeZKE8eo965YmvTpF4Ji9zW8M 5j43lrtXMHJB3e7EOh/VPBbg3qMXbII5EG0ESr1LlUClyB7yuf1Fzef0a6xGFJMqdLJQ 5jVvtDVXibK90H3fwmpKrcb/DJC0ftVwo0JdzqlrfMHKpo6iqPhvxael4a1+Nz/ldErX j7aQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721137698; x=1721742498; 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=KM8Ao0zGor69tQroBWIUZVg9uwOWjyC5j2aDW1h9Y7M=; b=RyW47hEVxfojWRgvk9Ik/QtCcTFiWB89ZF+sKPfPPMsTf927muSvU085501h0J9hVY IZSbvVk7/hthqWZZbE0iswq7yngfd0OLTlbwVn6sWPXqrwdrR9iU1IAE0xoTh9t5NSSu 6jeFaAz1HH+id7ELIRkY0Ut0F669d6fPCadvjoCnZAMZJKUG/3usBvQ/+pxJSuUKjByT NzqnXI7pq6+Spp4BQHsRaRoPS21wXLDpMvEMy3+VR+EgCOFjdyH2XmbEQcmtvcKgcVxL CO+ipebRTzjr8gq9+lgShjRJtt5Tgv/aeiE6aENq8Aiu1Bwjcom1NXrWCAjWu3H7+sX8 JeEQ== X-Forwarded-Encrypted: i=1; AJvYcCVdcAoluj0XYHTGK28d3tczaFtqHSJeMxzSh0naV3j6WQ8tgdCHBHykG+NtvrpLGndpTo4+Xll0A4GLD2Km0SnUGQo= X-Gm-Message-State: AOJu0YyHOrZRoDmntWRFSvB0LXmJ85YczJ8uaDF9fU53C/tHwPU48BFD +LRrs6ZG8WHPCPSITIwXMLXSIij07Iy1izcO1bnhM8H06DmqPt3cEDavkQY8qK8= X-Google-Smtp-Source: AGHT+IHrF8A8QPHCkRg6cY7Pr6jUMY+YOeOSFYt/dignGbQ+OVrmY981I/Z9G5rwzM03nO4wL9x+2A== X-Received: by 2002:a05:6512:1316:b0:52e:a699:2c8c with SMTP id 2adb3069b0e04-52edf038a3cmr1420761e87.45.1721137698585; Tue, 16 Jul 2024 06:48:18 -0700 (PDT) Received: from localhost (109-81-86-75.rct.o2.cz. [109.81.86.75]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-59b26996c4asm5004378a12.74.2024.07.16.06.48.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Jul 2024 06:48:18 -0700 (PDT) Date: Tue, 16 Jul 2024 15:48:17 +0200 From: Michal Hocko To: David Finkel Cc: Muchun Song , Andrew Morton , core-services@vimeo.com, Jonathan Corbet , Roman Gushchin , Shakeel Butt , 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 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: <20240715203625.1462309-2-davidf@vimeo.com> X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 77EF814000C X-Stat-Signature: jo4g6yux6nsrmacyg4asfgoqixpy85b8 X-Rspam-User: X-HE-Tag: 1721137700-454939 X-HE-Meta: U2FsdGVkX18K4YQqdJQW2+m1cQxBv1xr3gTQTK0CnLl2FfrAXl/cJyPUcmpEQ8RQWzQ8YBV36+2ohtMCNOV1hRhodRdzsyA6lsmIkSmFu+AUlH7K8IsurBBcT7Vz8r3LWNlS0D0ih2CPZ9dKrCqscdVbjZ78WGDrO3y1WUQ9QJTreXbHVRmtx6JqZwRAlAP7teRsK8kF5q+WVgFpRxpnWj7I4T5y9FMKqJ002BqNpf8zfUp4G/tq9q0y2YcGkVLOPGZqeNXu1rQNozj9AJWea8O05uETnUyMoyaDbVV2NKHGJDFXQ0Are05Lxp98ncRD2HLD+ISDq5tTrwpqeR/uJGjxbAMEKhYjDL6AU6nf0caQMP6mh9ilwMdws+aBfyxKQLLA6CsYP9imwoy1bso8XTrUe8EHlVoHWVb1aQD5h7rXpyhqTus/9HrZVV9OxSridFr6b7ne1HlPxg+/zD+ChYDDwI36x7lj2uu7tEUUYk8voHbuXBSY1vv+qQuFupcIN1AI/3kfWe868Tq5jGd/EqLO/Bmebf3c1hft90BQ3Xu9gmsQhlR8UwFOKfyDuwAPOEDOOyDmqAhX5JkA/i1SFAlL0rZW1BToB0Q61v8Bh7bGl4HRLzFd8ZG2X1qdgTi/GwmCC/xvCvTaDjjFzu6U4MI5pPZ0989FPmHZ6w0CtYCeBA0EJnNXWdPScSykMl6SQWYkshsRaqWxefM3aK7NCObJoaLMgJbkUuZM76bS+XbNcwFkEMnlSTP9/Gn5aXYtKWsFmCMU4LsoxeW+3fm0SDuils9PfwXPrQ+892lRZ1L/a6MeJYSYIFdqKWStMdL33CQowyvspRo1YoVXZEa5Lu97+vYBRUPnQlYDc07pM7hsFNXjvqY2uz8mN23gobveTy51LAlcH/GLE6bUV4MQ3TTgG4DP4qJ7MLEr6rw7uXaPwL23jyRaxBSxNlt/Ae4ESEp8CqTrEE2a1gMIU0W ndJPIz8r WhhUSxiJt/dHsaT7f1AkERZLdloEkb7QZHNRQ8JCAkxFh6AaL7BE/0avvTcc3NEzpa0o/bCvrj99DIUxZMXoZsV/calvRPSiH76TimK1wxVJpnNpHEgEnVTIpH9rfSzGX83qpBlKH/N7LfMRqxua4y90DpqzmQk40qXX4Mw+3VOAVQbYE4DBA7xOjI4bS0W1y0ouhcp/8JTHCX+kVbIFPVWihzFixY5FbolEJVZM/RgWzu8mv3FNeiKK3u8h445YNjxLZpBEeQ78J1i4Wtdec20Lr5ZAF7EnkmE1Oma/9sYbHbArghfduhcbJbH8WMbH52NkCd/XxFiZBVM+GxyT/+6ddKaHGbIUkR+FizKaTLF9+dyg= 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 Mon 15-07-24 16:36:26, 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), these systems need to track the peak memory usage to compute > system/container fullness when binpacking workitems. > > Signed-off-by: David Finkel 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 chnagelog could use some of the clarifications down the thread. Acked-by: Michal Hocko -- Michal Hocko SUSE Labs