linux-kernel - Re: cgroups(7): documenting cgroup.stat

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20180103135858.GA15200@castle.DHCP.thefacebook.com>
Date:   Wed, 3 Jan 2018 13:59:04 +0000
From:   Roman Gushchin <guro@...com>
To:     "Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
CC:     Tejun Heo <tj@...nel.org>, "Serge E. Hallyn" <serge@...lyn.com>,
        lkml <linux-kernel@...r.kernel.org>, <cgroups@...r.kernel.org>,
        linux-man <linux-man@...r.kernel.org>
Subject: Re: cgroups(7): documenting cgroup.stat

Hello, Michael!

> > Hm, basically any cgroup which had some pagecache, associated during the
> > lifetime, will spend some time in the dying state. This means that for
> > most cgroups this number will be non-zero for some amount of time,
> > which depends on global memory pressure.
> > It's also very implementation-defined, and will be likely changed
> > in the following kernel versions.
> > 
> > So, I'm not sure, that such an example will be useful for a user.
> > Until this number is huge and constantly growing, it shouldn't be
> > interesting for an user at all.
> 
> Fair enough. I added some vague text about resources needing to be freed
> before the cgroup is destroyed. See below.
> 
> 
> >>        nr_dying_descendants
> >>               This is the total number  of  dying  descendant  cgroups
> >>               underneath this cgroup.  A cgroup enters the dying state
> >>               after being deleted.  It remains in that  state  for  an
> >>               undefined  period  (which  will  depend  on system load)
> >>               before being destroyed.
> >>
> >>               A process can't be made a member of a dying cgroup,  and
> >>               a dying cgroup can't be brought back to life.
> > 
> > So, maybe it worth it to add a statement, that some amount of dying cgroups
> > is normal and it's not a signal of any problem?
> 
> Okay, I added some text along those lines. The first paragraph now reads:
> 
>        nr_dying_descendants
>               This is the total number  of  dying  descendant  cgroups
>               underneath this cgroup.  A cgroup enters the dying state
>               after being deleted.  It remains in that  state  for  an
>               undefined  period  (which  will  depend  on system load)
>               while  resources  are  freed  before   the   cgroup   is
>               destroyed.   Note  that  the presence of some cgroups in
>               the dying state is normal, and is not indicative of  any
>               problem.

Looks good to me!

Reviewed-by: Roman Gushchin <guro@...com>

Thank you!