On Tue, Jul 16, 2024 at 4:00 PM Tejun Heo <tj@xxxxxxxxxx> 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) > > But then again, maybe this is really niche, future usages will still remain > very restricted, and adding something more akin to PSI triggers is way > over-engineering it. Yeah, I think this is niche enough that it isn't worth over-engineering. There is some value to keeping broad compatibility for things moving from cgroups v1, too. > > Thanks. > > -- > tejun Thanks again, -- David Finkel Senior Principal Software Engineer, Core Services
