From: Roman Gushchin <guro-b10kYP2dOMg@public.gmane.org>
To: "Michael Kerrisk (man-pages)"
<mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
"Serge E. Hallyn" <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org>,
lkml <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-man <linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: cgroups(7): documenting cgroup.stat
Date: Tue, 2 Jan 2018 21:57:33 +0000 [thread overview]
Message-ID: <20180102215726.GA2606@castle> (raw)
In-Reply-To: <196c0cca-b573-8c65-2b5f-66376f79a836-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hello, Michael!
Thank you for working on this!
Please, find my comments below.
On Tue, Jan 02, 2018 at 07:22:33PM +0100, Michael Kerrisk (man-pages) wrote:
> Hello Roman,
>
> I wish to add documentation to cgroups(7) for the cgroup.stat file
> that you added in Linux 4.14. I wrote some text based on your text
> added to the cgroup-v2.txt file, but added some pieces, and also have
> a question (see below). The plain-text version for (easy review)
> is shown below. Could you please review this text? (Please note
> the FIXME!)
>
> The branch containing the pending cgroups(7) changes can be found at :
> https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/log/?h=draft_cgroup_updates
>
> [[
> Cgroups v2 cgroup.stat file
> Each cgroup in the v2 hierarchy contains a read-only
> cgroup.stat file (first introduced in Linux 4.14) that consists
> of lines containing key-value pairs. The following keys cur‐
> rently appear in this file:
>
> nr_descendants
> This is the total number of visible (i.e., living)
> descendant cgroups underneath this cgroup.
>
> ┌─────────────────────────────────────────────────────┐
> │FIXME │
> ├─────────────────────────────────────────────────────┤
> │For the following text on nr_dying_descendants, it │
> │would I think be helpful to describe a condrete │
> │example of when one might see nr_dying_descendants a │
> │nonzero value for this key. Ideally, the example │
> │would be one that the reader could easily reproduce. │
> │Is there such an example? │
> └─────────────────────────────────────────────────────┘
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.
>
> 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?
Otherwise looks very good to me.
Thank you!
Roman
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
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
Date: Tue, 2 Jan 2018 21:57:33 +0000 [thread overview]
Message-ID: <20180102215726.GA2606@castle> (raw)
In-Reply-To: <196c0cca-b573-8c65-2b5f-66376f79a836@gmail.com>
Hello, Michael!
Thank you for working on this!
Please, find my comments below.
On Tue, Jan 02, 2018 at 07:22:33PM +0100, Michael Kerrisk (man-pages) wrote:
> Hello Roman,
>
> I wish to add documentation to cgroups(7) for the cgroup.stat file
> that you added in Linux 4.14. I wrote some text based on your text
> added to the cgroup-v2.txt file, but added some pieces, and also have
> a question (see below). The plain-text version for (easy review)
> is shown below. Could you please review this text? (Please note
> the FIXME!)
>
> The branch containing the pending cgroups(7) changes can be found at :
> https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/log/?h=draft_cgroup_updates
>
> [[
> Cgroups v2 cgroup.stat file
> Each cgroup in the v2 hierarchy contains a read-only
> cgroup.stat file (first introduced in Linux 4.14) that consists
> of lines containing key-value pairs. The following keys cur‐
> rently appear in this file:
>
> nr_descendants
> This is the total number of visible (i.e., living)
> descendant cgroups underneath this cgroup.
>
> ┌─────────────────────────────────────────────────────┐
> │FIXME │
> ├─────────────────────────────────────────────────────┤
> │For the following text on nr_dying_descendants, it │
> │would I think be helpful to describe a condrete │
> │example of when one might see nr_dying_descendants a │
> │nonzero value for this key. Ideally, the example │
> │would be one that the reader could easily reproduce. │
> │Is there such an example? │
> └─────────────────────────────────────────────────────┘
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.
>
> 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?
Otherwise looks very good to me.
Thank you!
Roman
next prev parent reply other threads:[~2018-01-02 21:57 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-02 18:22 cgroups(7): documenting cgroup.stat Michael Kerrisk (man-pages)
2018-01-02 18:22 ` Michael Kerrisk (man-pages)
[not found] ` <196c0cca-b573-8c65-2b5f-66376f79a836-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2018-01-02 21:57 ` Roman Gushchin [this message]
2018-01-02 21:57 ` Roman Gushchin
2018-01-03 0:38 ` Michael Kerrisk (man-pages)
2018-01-03 0:38 ` Michael Kerrisk (man-pages)
[not found] ` <7cfbf94e-71c8-b49e-7483-79c3fa363191-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2018-01-03 13:59 ` Roman Gushchin
2018-01-03 13:59 ` Roman Gushchin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180102215726.GA2606@castle \
--to=guro-b10kyp2domg@public.gmane.org \
--cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org \
--cc=tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.