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 B2CD6C3DA4B for ; Wed, 17 Jul 2024 14:24:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4592D6B0092; Wed, 17 Jul 2024 10:24:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 409476B0093; Wed, 17 Jul 2024 10:24:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2F7876B0099; Wed, 17 Jul 2024 10:24:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 12E946B0092 for ; Wed, 17 Jul 2024 10:24:23 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id B2AFBC09EC for ; Wed, 17 Jul 2024 14:24:22 +0000 (UTC) X-FDA: 82349464764.09.956EB95 Received: from mail-pf1-f181.google.com (mail-pf1-f181.google.com [209.85.210.181]) by imf02.hostedemail.com (Postfix) with ESMTP id CD72980005 for ; Wed, 17 Jul 2024 14:24:20 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=vimeo.com header.s=google header.b=OqaSiB4A; spf=pass (imf02.hostedemail.com: domain of davidf@vimeo.com designates 209.85.210.181 as permitted sender) smtp.mailfrom=davidf@vimeo.com; dmarc=pass (policy=reject) header.from=vimeo.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1721226208; 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=Hj+0meFYGMBzJH7JTeMBoz5trc0iefK5H1vFgRRUTkQ=; b=gcHtxvmOSoqH2O2LHOTW9VUI4CvuuizfztkFqqUpX03pKpDhNdnBt4DgHH45YKBtUtLA9q xy22XKpSBYT+7+4riFbHEG8q4JCT0YVTbuobzq5gmJsTRnlvS1MWRQsoOiCsyhZxpnejF+ 7ALMb0AcLRc6RAoOMsx8JqO41Vqbyss= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=vimeo.com header.s=google header.b=OqaSiB4A; spf=pass (imf02.hostedemail.com: domain of davidf@vimeo.com designates 209.85.210.181 as permitted sender) smtp.mailfrom=davidf@vimeo.com; dmarc=pass (policy=reject) header.from=vimeo.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721226208; a=rsa-sha256; cv=none; b=rsG1C/X2roH0SmMwybLbN8akavR3fs+A0GOBw+gFljwx+Dge9uS9ZmYhdaKmys1jz/nocM sskZSTzlhpuxEM6s+fIGOnt1NbQgxtQHvEmmZmzt5Itn7JwIlRqZEJIGUUFaw5Qqg/CbBD r8UrPvG75NVbA522SeY1u/2EFuypUmw= Received: by mail-pf1-f181.google.com with SMTP id d2e1a72fcca58-70cec0ede71so173630b3a.3 for ; Wed, 17 Jul 2024 07:24:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vimeo.com; s=google; t=1721226259; x=1721831059; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Hj+0meFYGMBzJH7JTeMBoz5trc0iefK5H1vFgRRUTkQ=; b=OqaSiB4AQ2iWbhPgPJLMsPkW+9yb61Vl+6Iiw6zlluRKgPAwuc9fynFwl7G/2fmDzU Dlljmyb1vuBVtq5zLeGK8HdvtWN8PpMutr0SXFXlDJJ075Jevtthsanf+egH79Eha6r5 mAviXGW/LqbuzZTTDsqiSd8bkgQopr/DdNhho= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721226259; x=1721831059; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Hj+0meFYGMBzJH7JTeMBoz5trc0iefK5H1vFgRRUTkQ=; b=PIi4qUSdt8Iig8zl12FsksRyEmmBgUQCqSahMYah3Ym/PiP4HAAZKBFOnbyeVockYS /uPKJNB+EVFOVxgy0+vzQCEJW2urD0simA22ChccA3IBnaTFKAGGtfCi8DT7N4xKglaW JutQlT+Ig7a2fW4LNpwA1cfBJHF8d9RqvoPyRe9QBXMVcoJ4qBw7HyTZox9VMsWT7Lnd fAfq7M/SJLnVVlrkuAQFJvZU3PyIOQZ4lOUVbhAOBKuIpJB+0OZOwGpYr0ZPyiKPNUiT u3LF7Fu83FoSVhj69C0onKc5fiIaNCfLrrFpf1MBZqZki7irtscFhRv4Dgao36OFzTKM UTIA== X-Forwarded-Encrypted: i=1; AJvYcCViVkqFMljhRmMFvKqK9WgURPq9RmJ5Nw+iHohEPxDI7vnmQCYICBQjJOx6haIjsZq5D+oT/Wyq7c/rRA+rbk/ilzY= X-Gm-Message-State: AOJu0Yyw2sn6OBrUIVwZw3mlRPz2kbJmWKKvLXedqHjo/GTq5cFXIalL Lif/6n9abUuOrwpE8OLqseVfHbRtiKrZ0PnTUvdFokjkrtIJFELSFz+PynpBQPtXWpN0qknp4eg eZaHpfWjpZ2wQL/0iErGn+JrfKYBpTGiRPgrUWQ== X-Google-Smtp-Source: AGHT+IG7yfd9wMsTrpYq2tjdl/HBfFyDLsGQd9C65Mbwb0yGSE141RG5ss4fh1fsiJLtmZCVzC5HF2vflKzGMjOVuGw= X-Received: by 2002:a05:6a00:2d9a:b0:706:74b7:9d7d with SMTP id d2e1a72fcca58-70ce500d58fmr2233034b3a.25.1721226259125; Wed, 17 Jul 2024 07:24:19 -0700 (PDT) MIME-Version: 1.0 References: <20240715203625.1462309-1-davidf@vimeo.com> <20240715203625.1462309-2-davidf@vimeo.com> In-Reply-To: From: David Finkel Date: Wed, 17 Jul 2024 10:24:07 -0400 Message-ID: Subject: Re: [PATCH] mm, memcg: cg2 memory{.swap,}.peak write handlers To: Michal Hocko Cc: Tejun Heo , Muchun Song , Andrew Morton , core-services@vimeo.com, Jonathan Corbet , Roman Gushchin , Shuah Khan , Johannes Weiner , Zefan Li , cgroups@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, Shakeel Butt Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: CD72980005 X-Stat-Signature: p64x8m3s7hh6ufq1sypeqcp7tp9wjuk7 X-Rspam-User: X-HE-Tag: 1721226260-776377 X-HE-Meta: U2FsdGVkX1+9Kkcj3iQRnJxjuU7Y1i+VusWQ3Yj4vna3BouYopsugp7Gjzk4ljp5+Yo33930MsCZ7n8VAkVktzfSEB2NJSARoNHIzoKpA87oBePAu3nh3qf409xjigA3dxi9cadzkVwhwhEZA6ftQ3ih2bYWIPBu6hl2Bp7lnE/OicPUt1MxCz9TIVOReM/MOLY+6UHZ1is+rzqUB20mAl0q6B+zzHebxOxxJj/CO34FxOZQbtv9nNyPhq0iL03446KJsAk6aGu9hEYbpR9K1pJJ74BVJT6d2Rwm45XLY+Ca3tQ4Wl2WJxBYdidBXm/Lq3oiV656smNtN9XE5t6xZZ56Km4HQoyqYq1cYcfagOH97WxPOio1vhEHfJaUt6IP9WOVWSRYrSVOeIYpPS8SKHuLHFf/4Rpd4vIYN/0+c/hjMd0Lg3P4WSNK1Z5oiCHBbp5Nnm3dLvfVS8Qdp1hebN25pn50Q4wZhJpGKoamr1bykVGwynrb3PRK02KzO5AsOd+Oug1PKK3cQ4OimdSDk+1OlZsYJzB+8llSbGLnZJJin7JFZi+VGI5hP2jrjH9f57TM3Iyc1hWOZe+N60OAUfhHEsekvECFASVZctfw43gB0P91jCir6oFTSppHMMUSDkLHyordTJMo2NXNJkpK1JC1d12I0fv7djHBZsbtPn8izC6HMNdDizXqvLOm7LZz1DG2PLQH8u73sDfxISOs48ahcLvyJW7GcEXfyqfbA6ePQDDXZPWJoGq7J43XH+AFR/zQDGSN0OYox9eKJyslBBo/rkkYBdaRkGQK2X7/291G60bpWr1DJPW8nafZhAsIK+uB/P1EwTPf81EMSno4M5RBDrBAefwuL0rPohzzghTCSaeRmiuU+wtzuWYgUOqbFLwxlACldnBDabzHXpcl76veh4lPU+nh3wBxZYukEAg/ijbsKADYa894BgnIs2KDILZfiHGpgG1oFk1N9Fh Hj6vrGQK AmNrDwbNMo6PdRe4ez/l6fGrfUFLMvcKtLrAPK6RDx4Y78a9GXxIWa4z+bgcLAZUYWKAa9Tn8mI/IPS++iXslaxti2G4x8YYQr3Wn3vpp4ISFBr/f/v4RMW1YI8Y7ALqTLucVzxIAwBpL8vwUKvyqlKPcP2V8JVwCRgx1RPcphcdkvK9rruZwMkMqpt+w7VSHJ6h/ci3FrKbAx3VfVr7ITVlIFDJ2N0yLqvWManANqJKN9RNuQt1z+jeZ2rxHQuhwirDxYa8TYWVbhftMb7zl5PwvfQScm1TXyibKucSIlZbRhTyKHIBlxEYoPg== 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 Wed, Jul 17, 2024 at 2:26=E2=80=AFAM Michal Hocko wrot= e: > > On Tue 16-07-24 18:06:17, David Finkel wrote: > > On Tue, Jul 16, 2024 at 4:00=E2=80=AFPM Tejun Heo wrote= : > > > > > > Hello, > > > > > > On Tue, Jul 16, 2024 at 08:00:52PM +0200, Michal Hocko wrote: > > > ... > > > > > If we want to allow peak measurement of time periods, I wonder wh= ether we > > > > > could do something similar to pressure triggers - ie. let users r= egister > > > > > watchers so that each user can define their own watch periods. Th= is is more > > > > > involved but more useful and less error-inducing than adding rese= t to a > > > > > single counter. > > > > > > > > I would rather not get back to that unless we have many more users = that > > > > really need that. Absolute value of the memory consumption is a lon= g > > > > living concept that doesn't make much sense most of the time. Peopl= e > > > > just tend to still use it because it is much simpler to compare two= different > > > > values rather than something as dynamic as PSI similar metrics. > > > > > > The initial justification for adding memory.peak was that it's mostly= to > > > monitor short lived cgroups. Adding reset would make it used more wid= ely, > > > which isn't necessarily a bad thing and people most likely will find = ways to > > > use it creatively. I'm mostly worried that that's going to create a m= ess > > > down the road. Yeah, so, it's not widely useful now but adding reset = makes > > > it more useful and in a way which can potentially paint us into a cor= ner. > > > > This is a pretty low-overhead feature as-is, but we can reduce it furth= er by > > changing it so instead of resetting the watermark on any non-empty stri= ng, > > we reset only on one particular string. > > > > I'm thinking of something like "global_reset\n", so if we do something = like the > > PSI interface later, users can write "fd_local_reset\n", and get that > > nicer behavior. > > > > This also has the benefit of allowing "echo global_reset > > > /sys/fs/cgroup/.../memory.peak" to do the right thing. > > (better names welcome) > > This would be a different behavior than in v1 and therefore confusing > for those who rely on this in v1 already. So I wouldn't overengineer it > and keep the semantic as simple as possible. If we decide to add PSI > triggers they are completely independent on peak value because that is > reclaim based interface which by definition makes peak value very > dubious. That's fair. My only thought is that "write any non-empty string", is a very wide interf= ace to support, and limits other possible behaviors later. FWIW, I have patches with and without this narrowed interface ready to re-m= ail pending the outcome of this discussion. (both include additional use-case info in the changelog) Keeping the "all non-empty writes" behavior: https://github.com/dfinkel/linux/commit/5edb21882a88693024a95bbd76b4a8d4561= 348da With the narrowed interface: https://github.com/dfinkel/linux/commit/f341c8c0cf5fbdcf7af30e20b334e532df7= 4906d > -- > Michal Hocko > SUSE Labs Thanks, --=20 David Finkel Senior Principal Software Engineer, Core Services