Re: [PATCH] mm/memcontrol: Export memcg->watermark via sysfs for v2 memcg

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, May 6, 2022 at 10:15 PM Shakeel Butt <shakeelb@xxxxxxxxxx> wrote:
>
> On Fri, May 6, 2022 at 9:44 AM Ganesan Rajagopal <rganesan@xxxxxxxxxx> wrote:
> >
> > On Fri, May 6, 2022 at 9:26 PM Shakeel Butt <shakeelb@xxxxxxxxxx> wrote:
> > >
> > > On Fri, May 6, 2022 at 7:57 AM Johannes Weiner <hannes@xxxxxxxxxxx> wrote:
> > > >
> > > > On Thu, May 05, 2022 at 05:13:30AM -0700, Ganesan Rajagopal wrote:
> > > > > v1 memcg exports memcg->watermark as "memory.mem_usage_in_bytes" in
> > > > > sysfs. This is missing for v2 memcg though "memory.current" is exported.
> > > > > There is no other easy way of getting this information in Linux.
> > > > > getrsuage() returns ru_maxrss but that's the max RSS of a single process
> > > > > instead of the aggregated max RSS of all the processes. Hence, expose
> > > > > memcg->watermark as "memory.watermark" for v2 memcg.
> > > > >
> > > > > Signed-off-by: Ganesan Rajagopal <rganesan@xxxxxxxxxx>
> > > >
> > > > This wasn't initially added to cgroup2 because its usefulness is very
> > > > specific: it's (mostly) useless on limited cgroups, on long-running
> > > > cgroups, and on cgroups that are recycled for multiple jobs. And I
> > > > expect these categories apply to the majority of cgroup usecases.
> > > >
> > > > However, for the situation where you want to measure the footprint of
> > > > a short-lived, unlimited one-off cgroup, there really is no good
> > > > alternative. And it's a legitimate usecase. It doesn't cost much to
> > > > maintain this info. So I think we should go ahead with this patch.
> > > >
> > > > But please add a blurb to Documentation/admin-guide/cgroup-v2.rst.
> > >
> > > No objection from me. I do have two points: (1) watermark is not a
> > > good name for this interface, maybe max_usage or something. (2) a way
> > > to reset (i.e. write to it, reset it).
> >
> > Thanks for the feedback. I'll post an updated patch with your suggestions
> > (including updating the description). For resetting the value I assume
> > setting it to memory.current would be logical?
> >
>
> Yes, that is what v1 does, so no need to do anything different.

Sounds good. Thanks.

Ganesan




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux