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 2C567C3DA42 for ; Wed, 17 Jul 2024 06:23:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7AE276B0085; Wed, 17 Jul 2024 02:23:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 70FD16B0088; Wed, 17 Jul 2024 02:23:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 589366B0089; Wed, 17 Jul 2024 02:23:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 37F6C6B0085 for ; Wed, 17 Jul 2024 02:23:06 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id AD359A094A for ; Wed, 17 Jul 2024 06:23:05 +0000 (UTC) X-FDA: 82348251930.15.D1192C4 Received: from mail-ed1-f47.google.com (mail-ed1-f47.google.com [209.85.208.47]) by imf07.hostedemail.com (Postfix) with ESMTP id D57714001E for ; Wed, 17 Jul 2024 06:23:03 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b="Mh/q0cgH"; spf=pass (imf07.hostedemail.com: domain of mhocko@suse.com designates 209.85.208.47 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=1721197365; 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=m3+PhR/3a1eRlfLEg4VdiRyLGaVu24qNIiBH/dxTd5U=; b=aiJQQALq9TzHh6BncGC4E2RXdyRSfSEbXjhnPDMw90C0GLFtp2RDmXZRvuO5jlJ/C1Simp ZOhqcQfjDgB7IxhiGFUCcJ3l4XWChorTw/15/VLtXCD/EAD6LY6CmaZr9Q9a3/qpTDBCqi c9LSrinioeuSB288ti6SxcJnPixx3Lw= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b="Mh/q0cgH"; spf=pass (imf07.hostedemail.com: domain of mhocko@suse.com designates 209.85.208.47 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=1721197365; a=rsa-sha256; cv=none; b=3uL/nk4ZuUYi136cjsO3CPwXb/CndMTWE76KmdStliGtuPSadUqADT/UmbrMDV0X7vEc9e 2CRPMfM8U4vYq1W344itLMY2tffuw0PFL2ZolJYcktpGFLbAZJS8Rz9kKJpMzkHy18KZod k+5kERKGExz9qv/zUMXHDTZVymRJ0bQ= Received: by mail-ed1-f47.google.com with SMTP id 4fb4d7f45d1cf-58bac81f40bso7760953a12.1 for ; Tue, 16 Jul 2024 23:23:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1721197382; x=1721802182; 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=m3+PhR/3a1eRlfLEg4VdiRyLGaVu24qNIiBH/dxTd5U=; b=Mh/q0cgHb3ddObFHS5IZltNgjscV+uD5cMCzaiP5eC6b5//nh2XUS80JsSHc83S458 knnwE+FMWxczs9YAN4stbHoyEojclSFNJrC9OKxpYrGdJ7PH4DRgWvSaSCAytjYMhPp2 JlTxb3XDnYT6xRjl1OgSynf5y0FEaiG6HQNplBvsM5X9rfDTfrozSQnBKxpm3CwEabZ6 dP7hhCi3rNM1QgQho94m2kRb3SYpssfF2K3WDgB1hlWkhg9kiW/ZgEEUx+pf8ZDbMKxq K7FzZAt6kuv2SdxfOWV00ce91Lgbi842LUZOzSqNDDv61GJUM5XcSxV8iMZ/mm9v2We/ nf0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721197382; x=1721802182; 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=m3+PhR/3a1eRlfLEg4VdiRyLGaVu24qNIiBH/dxTd5U=; b=w9Dz4L1ODqhjeOkl8tu1/e6dH5D156heA6aKGFeO9HOvcN1YAxLYXlwtatOgaq/OYK iktSp7gXJo5rR1kkgAxbNJqPgGHGog+gIPoXtTCHGH2+VRxKePb2jyfVnvKWbEfqVthj IZmTPnfl8u+2rh+wtEORL6MKUdybwL2wOoLGegvqseIBvFr5m9uLqxAusILTJKswr2ay mS5EN4kIZOhF2xh6UAW5MEfm/siIz9rcQtAjG0mBbi6T+7fd/dEbD2Zgxpp+V4N0kHYn x6KaYkVUEsI6TvwypU0VKdt7Z+TQMzBd9mm+xT+51VJ+V19opDidU1vdbATNwx3lbta9 4pug== X-Forwarded-Encrypted: i=1; AJvYcCX2ukdzUUL4xaPcM2dcMA8j/b1xdNH1x1h7lSgj+44ncZzTvraeIWIHyiTHb/fOUTd3D2kiJiGbeJEiDEgKUccA5Vc= X-Gm-Message-State: AOJu0YwOab4fAwbXMop8CfM2fmmzy2HrFdEhLJ23GQvUzNYgp19LHXud osJiuKWurw/DEJ3UxYDzki1ybAMYM0do3inKxfNQpQ2syqenZMa5xRsLZXA4KJA= X-Google-Smtp-Source: AGHT+IETxd/duCNWxFX80WiV+h81gWmi7n0C4ofi3OJjO3PtYvu2atHLt5BB7L7ENAB2bH4yvHwxbQ== X-Received: by 2002:a05:6402:254f:b0:58a:e73f:6edb with SMTP id 4fb4d7f45d1cf-5a05d2de409mr568638a12.40.1721197382120; Tue, 16 Jul 2024 23:23:02 -0700 (PDT) Received: from localhost (109-81-86-75.rct.o2.cz. [109.81.86.75]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-59eaaee1c97sm2829868a12.28.2024.07.16.23.23.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Jul 2024 23:23:01 -0700 (PDT) Date: Wed, 17 Jul 2024 08:23:01 +0200 From: Michal Hocko To: Tejun Heo 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-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: D57714001E X-Stat-Signature: 86kbsam7g7pfbr13mpy93tex3qj73crh X-HE-Tag: 1721197383-715632 X-HE-Meta: U2FsdGVkX1/edYsFFwrCLCthXmCkkPzbxatorEbgg43l0GVEo1QjM15m937byEEgcCmVyqq/T8uy8CUOkwAIQeLrVXKkJqJdoTkyDZjIFC2LUUy16xuhxhdav+nRNJK6AOxNz9qlQ3iTxtdDCW5rjHjDjnDOBQU8cAXgXhd0SOT+PZjy31tpyqF4J8cPm3HL/4QzVDt/IEh68B1rprpt1wL+bQ84dE8CwB92hY5npeFogS+BVUTyHLS2w/ZKAQuxxQzmcuC8UQzMUqnsw10UWSJhrk5wzjNjHMq6/CaQEIlK/6AOSxak6oWEgY4xI+fLeim+JJbAL0wxv8ERNACPp2brApvMCevR7cXJn6KdY1OgWXEicdi73syXy3q+9we6z+1a/WrNjORWS3qunyMCwUJytXSUwoN1XPPsXYkPxhQrhBuquGH81LXlxxFodilCJdmJNDZE6/YUGBW54nSQ4Pb4snSA7uYg/6I+RaOI87/7Z/zWNnKEVZiBsC93kJLWTpvO5WtsEyCxEFSnh3J/eFeRyQYw4mT+TUaE+hzsVmrd1Q/5KJAGah/XO3kSDeNYmfr9XVbcZ7iaIhJGF3/UUm6e+hLCWfmHlseNqRWQqnusZGAp6WO1jgp4B6+A/aQZIVMoZ5WW7owzZNjeF8MJAlnVOMZxiUV0GtoRVKmkofcjXRTl/YEL8G71r8gfqfG/aP4DcJpqzEJC7jZPN3nGOkm4Ut+MtoJp/pfpplbHXWX27YU5FUMDi75arG+zs8awk8gyz3wSvyl7YBoIMR5PPRHLmG2Q3Vb310Z7MXDSXwOp0hoGpTmO/DGbZAwGXE1iWv2yLidtVthpRWppLCYXvHkPvOZ95sb769QNauVI86GBW2pr/ISZ/AbP5GeXfdvYcOhBKqpKUbJwGCUPKYmBpJN/3n9NGE7clHcVnLML9z28bqg1rPSE2lfiUE/X0V+s0IW488X5Tag+9QzvI1u dEOd25+5 qzAuS1KLBeAuKMcV+41xAJwT8qINK7XwBLWdjVa0RbLojoTyJkkT+nVDpDY8Ha6ItPmA8/IPowTVWZXD13UlmOVMGjMskoQ6TKy7p8SfiydgfASCz9+G0hYc0Jo1g3/UYQoLfQaweFv96I/aFyokc3kYFhvEjlUk6IDQ6uDx5EcTQYon7rkW14ARyhIHFZ7I5GyCYZ+B6yaMTqCPg5+DjLXBZXU5c04cuhdXD/s9cWDCCHB7Mzm47KIJds6gi9utZJiYfQog/+z9FT7jbpI+cQnaWl24TVePOIglg 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 10:00:10, 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 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. > > > > 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 long > > living concept that doesn't make much sense most of the time. People > > 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 widely, > 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 mess > 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 corner. I really fail to see how this would cause problems with future maintainability. It is not like we are trying to deprecate this memory.peak. I am also not sure this makes it so much more attractive that people would start using it just because they can reset the value. It makes sense to extend our documentation and actually describe pitfalls. -- Michal Hocko SUSE Labs