Date: Wed, 3 Jan 2018 13:59:04 +0000
From: Roman Gushchin <guro@fb.com>
To: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
CC: Tejun Heo <tj@kernel.org>, "Serge E. Hallyn" <serge@hallyn.com>,
        lkml <linux-kernel@vger.kernel.org>, <cgroups@vger.kernel.org>,
        linux-man <linux-man@vger.kernel.org>
Subject: Re: cgroups(7): documenting cgroup.stat
Message-ID: <20180103135858.GA15200@castle.DHCP.thefacebook.com>
References: <196c0cca-b573-8c65-2b5f-66376f79a836@gmail.com>
 <20180102215726.GA2606@castle>
 <7cfbf94e-71c8-b49e-7483-79c3fa363191@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <7cfbf94e-71c8-b49e-7483-79c3fa363191@gmail.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Jan 2018 13:59:15.7253 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 05d1e2ff-3720-4c0e-6d93-08d552b22dc0
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR15MB1086
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-01-03_10:,,
 signatures=0
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Return-Path: <linux-kernel-owner@vger.kernel.org>

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@fb.com>

Thank you!