Re: cgroups(7): documenting cgroup.stat

[Roman Gushchin]

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@xxxxxx>

Thank you!