From: Roman Gushchin <roman.gushchin@linux.dev>
To: Tejun Heo <tj@kernel.org>
Cc: Michal Hocko <mhocko@suse.com>, David Finkel <davidf@vimeo.com>,
Muchun Song <muchun.song@linux.dev>,
Andrew Morton <akpm@linux-foundation.org>,
core-services@vimeo.com, Jonathan Corbet <corbet@lwn.net>,
Shakeel Butt <shakeelb@google.com>, Shuah Khan <shuah@kernel.org>,
Johannes Weiner <hannes@cmpxchg.org>,
Zefan Li <lizefan.x@bytedance.com>,
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
Date: Tue, 16 Jul 2024 17:01:15 +0000 [thread overview]
Message-ID: <ZpanW41dQ8DimbA3@google.com> (raw)
In-Reply-To: <ZpajW9BKCFcCCTr-@slm.duckdns.org>
On Tue, Jul 16, 2024 at 06:44:11AM -1000, Tejun Heo wrote:
> Hello,
>
> On Tue, Jul 16, 2024 at 03:48:17PM +0200, Michal Hocko wrote:
> ...
>
> The removal of resets was intentional. The problem was that it wasn't clear
> who owned those counters and there's no way of telling who reset what when.
> It was easy to accidentally end up with multiple entities that think they
> can get timed measurement by resetting.
>
> So, in general, I don't think this is a great idea. There are shortcomings
> to how memory.peak behaves in that its meaningfulness quickly declines over
> time. This is expected and the rationale behind adding memory.peak, IIRC,
> was that it was difficult to tell the memory usage of a short-lived cgroup.
>
> 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.
It's definitely a better user interface and I totally agree with you regarding
the shortcomings of the proposed interface with a global reset. But if you let
users to register a (potentially large) number of watchers, it might be quite
bad for the overall performance, isn't it? To mitigate it, we'll need to reduce
the accuracy of peak values. And then the question is why not just poll it
periodically from userspace?
next prev parent reply other threads:[~2024-07-16 17:01 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-15 20:36 [PATCH] mm, memcg: cg2 memory{.swap,}.peak write handlers David Finkel
2024-07-15 20:36 ` David Finkel
2024-07-15 20:42 ` David Finkel
2024-07-15 20:46 ` David Finkel
2024-07-16 7:20 ` Michal Hocko
2024-07-16 12:47 ` David Finkel
2024-07-16 13:19 ` Michal Hocko
2024-07-16 13:39 ` David Finkel
2024-07-16 13:48 ` Michal Hocko
2024-07-16 13:54 ` David Finkel
2024-07-16 16:44 ` Tejun Heo
2024-07-16 17:01 ` Roman Gushchin [this message]
2024-07-16 17:20 ` David Finkel
2024-07-16 19:53 ` Tejun Heo
2024-07-16 17:10 ` David Finkel
2024-07-16 19:48 ` Tejun Heo
2024-07-16 20:18 ` David Finkel
2024-07-16 18:00 ` Michal Hocko
2024-07-16 20:00 ` Tejun Heo
2024-07-16 22:06 ` David Finkel
2024-07-17 6:26 ` Michal Hocko
2024-07-17 14:24 ` David Finkel
2024-07-17 15:46 ` Michal Hocko
2024-07-17 6:23 ` Michal Hocko
2024-07-17 17:04 ` Johannes Weiner
2024-07-17 20:14 ` David Finkel
2024-07-17 20:44 ` Johannes Weiner
2024-07-17 21:13 ` David Finkel
2024-07-17 23:48 ` Waiman Long
2024-07-18 1:24 ` Tejun Heo
2024-07-18 2:17 ` Roman Gushchin
2024-07-18 2:22 ` Waiman Long
2024-07-18 7:21 ` Michal Hocko
2024-07-18 21:49 ` David Finkel
2024-07-19 3:23 ` Waiman Long
2024-07-22 15:18 ` David Finkel
-- strict thread matches above, loose matches on Subject: below --
2024-07-22 15:17 [PATCH] mm, memcg: cg2 memory{.swap,}.peak write handlers (fd-local edition) David Finkel
2024-07-22 15:17 ` [PATCH] mm, memcg: cg2 memory{.swap,}.peak write handlers David Finkel
2024-07-22 18:22 ` Roman Gushchin
2024-07-22 19:30 ` David Finkel
2024-07-22 19:47 ` Waiman Long
2024-07-22 23:06 ` David Finkel
2023-12-04 19:41 David Finkel
2023-12-04 23:33 ` Shakeel Butt
2023-12-05 9:07 ` Michal Hocko
2023-12-05 16:00 ` David Finkel
2023-12-06 8:45 ` Michal Hocko
2024-02-07 21:06 ` David Finkel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZpanW41dQ8DimbA3@google.com \
--to=roman.gushchin@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=corbet@lwn.net \
--cc=core-services@vimeo.com \
--cc=davidf@vimeo.com \
--cc=hannes@cmpxchg.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lizefan.x@bytedance.com \
--cc=mhocko@suse.com \
--cc=muchun.song@linux.dev \
--cc=shakeelb@google.com \
--cc=shuah@kernel.org \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).