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 C223AC3DA42 for ; Wed, 17 Jul 2024 06:26:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 58CDB6B0089; Wed, 17 Jul 2024 02:26:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 517016B008C; Wed, 17 Jul 2024 02:26:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3B6366B0092; Wed, 17 Jul 2024 02:26:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 1CE456B0089 for ; Wed, 17 Jul 2024 02:26:06 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id C713C1C16E0 for ; Wed, 17 Jul 2024 06:26:05 +0000 (UTC) X-FDA: 82348259490.30.B8B2639 Received: from mail-lf1-f42.google.com (mail-lf1-f42.google.com [209.85.167.42]) by imf18.hostedemail.com (Postfix) with ESMTP id B80E61C0020 for ; Wed, 17 Jul 2024 06:26:03 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=dTgRQLdP; spf=pass (imf18.hostedemail.com: domain of mhocko@suse.com designates 209.85.167.42 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=1721197511; 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=kRZCoDkETaEFOBCewGIFpdrgG+eZN4FZNraXMVegoL0=; b=l3TAdP2r7t1u/uxCy2dWEXF4MBP5CLZc9AO54sPpb/rEoKVIi6JBvKkJu6pWGZ/yBZX9ok oZZZyp2WmkSOGsaIT8B1Epf0TRVItMNwaMzxqgSihqSYgmVLds3ihhWy/bU12RGyq9HDfc LsTx2X5OwZA4LeBvuVaMHmkCKVT8cTE= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=dTgRQLdP; spf=pass (imf18.hostedemail.com: domain of mhocko@suse.com designates 209.85.167.42 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=1721197511; a=rsa-sha256; cv=none; b=wDx72ki+ULvdepbCLDQph7eERbWlSMAWQYxr8fp8wVSLJH6rRx5hOIDRiJzyRds76ODbF3 dsOnxtJVU3x4JKrGRxW34ugmckOhoAnZCX2bM0SjBbYQBv5fkO0Bttxi4ByYNCvErdelgC sN5zAD/KvrDeNRxgVRI3dnSfGwEwxXE= Received: by mail-lf1-f42.google.com with SMTP id 2adb3069b0e04-52e98087e32so7690138e87.2 for ; Tue, 16 Jul 2024 23:26:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1721197562; x=1721802362; 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=kRZCoDkETaEFOBCewGIFpdrgG+eZN4FZNraXMVegoL0=; b=dTgRQLdPShQhjJkcLMFIPxrOusMret1VvRUzTgN4Ce/ogxTkV9OSuswjnVUgX5oPRf dmMTxyXNqXq/QyjJaG8d878hiCq11WbNvEOUmbmdPgZcKaek2OHvl/e9BGZwkle2vsZ1 b8cHX9GkVtIOtNf/ERVChLZWn5wnHsj6NeqIoftC38vZ/L6vV5AAUBgIvs5LChuQ8gr1 gQewr9XhN8b6hkGXjnvXeM3QDGpht26omrheS+Vb/oLivulEmOg8m8MIpFiM6N69ffV6 Exp8XAcr2QFIT+BzMmfh79vtTuYxOYtfEWfMbtWUCxLRMkcYyo4Qdv6C7p3FUyhFhMTs SbZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721197562; x=1721802362; 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=kRZCoDkETaEFOBCewGIFpdrgG+eZN4FZNraXMVegoL0=; b=b+84W2+uA/5PwepQazSBwtFVNR5LqnxG1Xm4U5tcXINVzk6TC3LvHn/pVK+ArJOtVx U5pC1jeTjjxPJLtJRHhhbWE0W7hWOHRgvSE9RKcWZmPNGB7mJl/CFlFW8I36ys2xVOJ5 u43EKegJWQIEr2rM0xEB9qRbMQlx47FqErGWojTzr60uIqxVJomKUXK4Fy+A9lBmnq2W WKm9nfZwT0KC7pvsMSkBjIzhCmWhSeSGs0HO1Wy71FjpnnSuR0sVJcwckJI/AqmnOfKy krsBv8FseLMTErIdhA8/Ym4dMdFCfdo6iK+XhOrv22KGnWZJ9hu20DUoZvpgQquXY/Xz 7rlQ== X-Forwarded-Encrypted: i=1; AJvYcCXJPLc4Z0KnyJOAcjXmc0KIQwVbA3+fsnloBF/2wlRf7VOkD6T3W3GabZMbbCApXD42VpKYx4hcFbbRPC07VOqbE2A= X-Gm-Message-State: AOJu0YyeV4gSt9CztNZcf1ni00kL8XUdjw8RHTuLyTRsof3k7D4dvkqA Hn5p3QWlXn1C1NCk8s8TzJ25TdooZNoDTXWllFkmPyJdsI6e3Gz3AwyvTjPAvzI= X-Google-Smtp-Source: AGHT+IGDEwk+nZqPqfNzpH3tY2qHsGGwHFWpWnZPOMmrbDmZO3jaXfhbMrl3VS0/+lWJ0Ywpz+aWEA== X-Received: by 2002:a05:6512:104a:b0:52e:9ec8:a3fd with SMTP id 2adb3069b0e04-52ee542718dmr459428e87.45.1721197561796; Tue, 16 Jul 2024 23:26:01 -0700 (PDT) Received: from localhost (109-81-86-75.rct.o2.cz. [109.81.86.75]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a79bc5b4f87sm406498866b.48.2024.07.16.23.26.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Jul 2024 23:26:01 -0700 (PDT) Date: Wed, 17 Jul 2024 08:26:00 +0200 From: Michal Hocko To: David Finkel 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 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: rspam06 X-Rspamd-Queue-Id: B80E61C0020 X-Stat-Signature: pq9o69w7rdkmd4u9ippb3e58afub94yi X-Rspam-User: X-HE-Tag: 1721197563-627978 X-HE-Meta: U2FsdGVkX18wJmX6EsprTiDgWdM10LxIcJyIwwK53hqpknLVlfQxuB4m5HryHxZf1UkdJVWVl/Jo5J7o35g/b+e/ZUmlc2E8/KbAZJxm3XvAPCJ7ilV9eZurp0a20hA+L1SnpCTGmdBkQfWsWCeAhlEZawpVbhS2DaS8tGavAYl/Z7x3QUEXN42ZAxLpoIL6AriFSdTRFNRo2JvqZuSf1blRia/61F8+II41qthD/odKYLX5vjOUfUp1VlOb2chgny37WYUzv4Hir93h9KD5kB102jW63Ynnbtf7ph0Jeec/1r2VtzyTt+/RJbQBFgYqSkJk4Z9UccrU5LGwNrOgnZpDb9+5kz/oJoJlvo6SLlWlItxajvBV9BhclFj0VWVog2ckEGYabZZM8LAWHP0OCn6aWygcjUJNNh7OqPqy2Ta69830oNW8k9ysozsB2P5KT2wlLL/mNCiD4SezW7wyFFLmNbCxgMH3wy6CAdGf6PBJAkohr1YIQ6qR+LQM4q0wDx3G+hsdpAiFX/zimTfleydaozON0nwqQvkYs8fFZBvhnog3d+fGbCjvu71Ui9K5cKXWmiKBUI8svsjDcI4ZXdIELSezkLkVN2k09udTV033/HEYLx320rBmcDupYktSZ84dMsX8rEZdM1+jOvRmTUnwKaIsbGGoXoSpDQ8lMDIKMG/YLZbNtZ1mGy+fibGkfjN3OJuoI82OCoVZBTjr0hyoZBHmyHi6MvX/Ag4nDmQ3kFUjw45ByeWT5MH/1mN1aV2ZLBg1v1zcmQknUxfB0Yi/cLhJXUf2SB7oazgAHFpvm8kGIZJCo8QV67nEdXo+R1lu3vNPLWXkFBdwM7CpOhrHmcCtJj+3IiE/PRdle9XZTjLtxpvHJo/HSMmbmlyzsUYVejWMUw3i8lo0weV+hDQ0srpZyTtVWjQnhLzYZamFB0QSwO8N4KxU1St8UnAOM/NtMX80WwIZM8TJ2jg JGfZWpPH /Hxm20ynlbMdLOHVvtXIAhRi/tnX2JPPieoc48ZFUXghWUnqq1mCcFmDIZQKEdI7dKQLDGDokpdxfam4+oMPEcQpc9PjzyzVn4SWgZmSjm0kRYcu+EzB7M5w7e16Jwy9bJkrIzY+F0DiVF5swf7v7yroZhdDVmL0Fma/9xceO6fFs2e2PlFnaKt8E9SPAxsp0+wrlTIFbCKvM/jzdwupI/VTaoXKhrb99LNMzVocEcDMMCCVdJawQY9BBbrLhsz2ljf5TkmpJs3QMfnPhv6MvRZqHhgh7I8/+Y8LW5Pj4KYzsXoKdPnTkfrYIoj1FQtn5rsLhWJpP7pySbf+YtagX+dys0we0L589P3HRhP+gJCjuyJHZle2Bg9sNWQ== 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 18:06:17, David Finkel wrote: > On Tue, Jul 16, 2024 at 4:00 PM 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. > > This is a pretty low-overhead feature as-is, but we can reduce it further by > changing it so instead of resetting the watermark on any non-empty string, > 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. -- Michal Hocko SUSE Labs