* [PATCH v3 7/7] cgroup: document cgroup v2 freezer interface [not found] <20181117003830.15344-1-guro@fb.com> @ 2018-11-17 0:38 ` Roman Gushchin 2018-11-17 8:02 ` Mike Rapoport 0 siblings, 1 reply; 4+ messages in thread From: Roman Gushchin @ 2018-11-17 0:38 UTC (permalink / raw) To: Tejun Heo Cc: Oleg Nesterov, cgroups, linux-kernel, kernel-team, Roman Gushchin, linux-doc Describe cgroup v2 freezer interface in the cgroup v2 admin guide. Signed-off-by: Roman Gushchin <guro@fb.com> Cc: Tejun Heo <tj@kernel.org> Cc: linux-doc@vger.kernel.org Cc: kernel-team@fb.com --- Documentation/admin-guide/cgroup-v2.rst | 26 +++++++++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst index 184193bcb262..a065c0bed88c 100644 --- a/Documentation/admin-guide/cgroup-v2.rst +++ b/Documentation/admin-guide/cgroup-v2.rst @@ -862,6 +862,8 @@ All cgroup core files are prefixed with "cgroup." populated 1 if the cgroup or its descendants contains any live processes; otherwise, 0. + frozen + 1 if the cgroup is frozen; otherwise, 0. cgroup.max.descendants A read-write single value files. The default is "max". @@ -895,6 +897,30 @@ All cgroup core files are prefixed with "cgroup." A dying cgroup can consume system resources not exceeding limits, which were active at the moment of cgroup deletion. + cgroup.freeze + A read-write single value file which exists on non-root cgroups. + Allowed values are "0" and "1". The default is "0". + + Writing "1" to the file causes freezing of the cgroup and all + descendant cgroups. This means that all belonging processes will + be stopped and will not run until the cgroup will be explicitly + unfrozen. Freezing of the cgroup may take some time; when the process + is complete, the "frozen" value in the cgroup.events control file + will be updated and the corresponding notification will be issued. + + Cgroup can be frozen either by its own settings, either by settings + of any ancestor cgroups. If any of ancestor cgroups is frozen, the + cgroup will remain frozen. + + Processes in the frozen cgroup can be killed by a fatal signal. + They also can enter and leave a frozen cgroup: either by an explicit + move by a user, either if freezing of the cgroup races with fork(). + If a cgroup is moved to a frozen cgroup, it stops. If a process is + moving out of a frozen cgroup, it becomes running. + + Frozen status of a cgroup doesn't affect any cgroup tree operations: + it's possible to delete a frozen (and empty) cgroup, as well as + create new sub-cgroups. Controllers =========== -- 2.17.2 ^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH v3 7/7] cgroup: document cgroup v2 freezer interface 2018-11-17 0:38 ` [PATCH v3 7/7] cgroup: document cgroup v2 freezer interface Roman Gushchin @ 2018-11-17 8:02 ` Mike Rapoport 2018-11-19 17:42 ` Roman Gushchin 0 siblings, 1 reply; 4+ messages in thread From: Mike Rapoport @ 2018-11-17 8:02 UTC (permalink / raw) To: Roman Gushchin Cc: Tejun Heo, Oleg Nesterov, cgroups, linux-kernel, kernel-team, Roman Gushchin, linux-doc Hi, On Fri, Nov 16, 2018 at 04:38:30PM -0800, Roman Gushchin wrote: > Describe cgroup v2 freezer interface in the cgroup v2 admin guide. > > Signed-off-by: Roman Gushchin <guro@fb.com> > Cc: Tejun Heo <tj@kernel.org> > Cc: linux-doc@vger.kernel.org > Cc: kernel-team@fb.com > --- > Documentation/admin-guide/cgroup-v2.rst | 26 +++++++++++++++++++++++++ > 1 file changed, 26 insertions(+) > > diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst > index 184193bcb262..a065c0bed88c 100644 > --- a/Documentation/admin-guide/cgroup-v2.rst > +++ b/Documentation/admin-guide/cgroup-v2.rst > @@ -862,6 +862,8 @@ All cgroup core files are prefixed with "cgroup." > populated > 1 if the cgroup or its descendants contains any live > processes; otherwise, 0. > + frozen > + 1 if the cgroup is frozen; otherwise, 0. > > cgroup.max.descendants > A read-write single value files. The default is "max". > @@ -895,6 +897,30 @@ All cgroup core files are prefixed with "cgroup." > A dying cgroup can consume system resources not exceeding > limits, which were active at the moment of cgroup deletion. > > + cgroup.freeze > + A read-write single value file which exists on non-root cgroups. > + Allowed values are "0" and "1". The default is "0". > + > + Writing "1" to the file causes freezing of the cgroup and all > + descendant cgroups. This means that all belonging processes will > + be stopped and will not run until the cgroup will be explicitly > + unfrozen. Freezing of the cgroup may take some time; when the process "when the process is complete" sounds somewhat ambiguous, it's unclear whether freezing is complete or the process that's being frozen is complete. Maybe "when this action is completed"? > + is complete, the "frozen" value in the cgroup.events control file > + will be updated and the corresponding notification will be issued. Can you please clarify how exactly cgroup.events would be updated? > + Cgroup can be frozen either by its own settings, either by settings ^ A cgroup ... and maybe there are more "a" and "the" that should be fixed, it's hard for me to tell. Also, I believe "either ..., or ..." sounds better than "either ..., either ..." > + of any ancestor cgroups. If any of ancestor cgroups is frozen, the > + cgroup will remain frozen. > + > + Processes in the frozen cgroup can be killed by a fatal signal. > + They also can enter and leave a frozen cgroup: either by an explicit > + move by a user, either if freezing of the cgroup races with fork(). ditto > + If a cgroup is moved to a frozen cgroup, it stops. If a process is ^ process? > + moving out of a frozen cgroup, it becomes running. ^ moved > + Frozen status of a cgroup doesn't affect any cgroup tree operations: > + it's possible to delete a frozen (and empty) cgroup, as well as > + create new sub-cgroups. Maybe it's also worth adding that freezing a process has no effect on its memory consumption, at least directly. > Controllers > =========== > -- > 2.17.2 > -- Sincerely yours, Mike. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v3 7/7] cgroup: document cgroup v2 freezer interface 2018-11-17 8:02 ` Mike Rapoport @ 2018-11-19 17:42 ` Roman Gushchin 2018-11-20 14:06 ` Mike Rapoport 0 siblings, 1 reply; 4+ messages in thread From: Roman Gushchin @ 2018-11-19 17:42 UTC (permalink / raw) To: Mike Rapoport Cc: Roman Gushchin, Tejun Heo, Oleg Nesterov, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, Kernel Team, linux-doc@vger.kernel.org On Sat, Nov 17, 2018 at 12:02:28AM -0800, Mike Rapoport wrote: > Hi, > > On Fri, Nov 16, 2018 at 04:38:30PM -0800, Roman Gushchin wrote: > > Describe cgroup v2 freezer interface in the cgroup v2 admin guide. > > > > Signed-off-by: Roman Gushchin <guro@fb.com> > > Cc: Tejun Heo <tj@kernel.org> > > Cc: linux-doc@vger.kernel.org > > Cc: kernel-team@fb.com > > --- > > Documentation/admin-guide/cgroup-v2.rst | 26 +++++++++++++++++++++++++ > > 1 file changed, 26 insertions(+) > > > > diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst > > index 184193bcb262..a065c0bed88c 100644 > > --- a/Documentation/admin-guide/cgroup-v2.rst > > +++ b/Documentation/admin-guide/cgroup-v2.rst > > @@ -862,6 +862,8 @@ All cgroup core files are prefixed with "cgroup." > > populated > > 1 if the cgroup or its descendants contains any live > > processes; otherwise, 0. > > + frozen > > + 1 if the cgroup is frozen; otherwise, 0. > > > > cgroup.max.descendants > > A read-write single value files. The default is "max". > > @@ -895,6 +897,30 @@ All cgroup core files are prefixed with "cgroup." > > A dying cgroup can consume system resources not exceeding > > limits, which were active at the moment of cgroup deletion. > > > > + cgroup.freeze > > + A read-write single value file which exists on non-root cgroups. > > + Allowed values are "0" and "1". The default is "0". > > + > > + Writing "1" to the file causes freezing of the cgroup and all > > + descendant cgroups. This means that all belonging processes will > > + be stopped and will not run until the cgroup will be explicitly > > + unfrozen. Freezing of the cgroup may take some time; when the process > > "when the process is complete" sounds somewhat ambiguous, it's unclear > whether freezing is complete or the process that's being frozen is > complete. > > Maybe "when this action is completed"? > > > + is complete, the "frozen" value in the cgroup.events control file > > + will be updated and the corresponding notification will be issued. > > Can you please clarify how exactly cgroup.events would be updated? > > > + Cgroup can be frozen either by its own settings, either by settings > > ^ A cgroup ... and maybe there are more "a" and "the" that should be > fixed, it's hard for me to tell. > > Also, I believe "either ..., or ..." sounds better than "either ..., > either ..." > > > + of any ancestor cgroups. If any of ancestor cgroups is frozen, the > > + cgroup will remain frozen. > > + > > + Processes in the frozen cgroup can be killed by a fatal signal. > > + They also can enter and leave a frozen cgroup: either by an explicit > > + move by a user, either if freezing of the cgroup races with fork(). > > ditto > > > + If a cgroup is moved to a frozen cgroup, it stops. If a process is > > ^ process? > > > + moving out of a frozen cgroup, it becomes running. > > ^ moved Hello, Mike! Thanks for the review! I agree with all comments above; fixes queued for v4. > > > + Frozen status of a cgroup doesn't affect any cgroup tree operations: > > + it's possible to delete a frozen (and empty) cgroup, as well as > > + create new sub-cgroups. > > Maybe it's also worth adding that freezing a process has no effect on its > memory consumption, at least directly. Hm, isn't it the expected behavior? In any case, I assume that cgroup.freeze knob description is not the best place for a such explanations. Maybe it's better to add a standalone paragraph with the description of the frozen process state, what's expected to work, what's not, etc. I'd return to this question a bit later, when we'll agree on the user interface and the implementation. Thanks! ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v3 7/7] cgroup: document cgroup v2 freezer interface 2018-11-19 17:42 ` Roman Gushchin @ 2018-11-20 14:06 ` Mike Rapoport 0 siblings, 0 replies; 4+ messages in thread From: Mike Rapoport @ 2018-11-20 14:06 UTC (permalink / raw) To: Roman Gushchin Cc: Roman Gushchin, Tejun Heo, Oleg Nesterov, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, Kernel Team, linux-doc@vger.kernel.org On Mon, Nov 19, 2018 at 05:42:48PM +0000, Roman Gushchin wrote: > On Sat, Nov 17, 2018 at 12:02:28AM -0800, Mike Rapoport wrote: > > Hi, > > > > On Fri, Nov 16, 2018 at 04:38:30PM -0800, Roman Gushchin wrote: > > > Describe cgroup v2 freezer interface in the cgroup v2 admin guide. > > > > > > Signed-off-by: Roman Gushchin <guro@fb.com> > > > Cc: Tejun Heo <tj@kernel.org> > > > Cc: linux-doc@vger.kernel.org > > > Cc: kernel-team@fb.com > > > --- > > > Documentation/admin-guide/cgroup-v2.rst | 26 +++++++++++++++++++++++++ > > > 1 file changed, 26 insertions(+) > > > > > > diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst > > > index 184193bcb262..a065c0bed88c 100644 > > > --- a/Documentation/admin-guide/cgroup-v2.rst > > > +++ b/Documentation/admin-guide/cgroup-v2.rst > > > @@ -862,6 +862,8 @@ All cgroup core files are prefixed with "cgroup." > > > populated > > > 1 if the cgroup or its descendants contains any live > > > processes; otherwise, 0. > > > + frozen > > > + 1 if the cgroup is frozen; otherwise, 0. > > > > > > cgroup.max.descendants > > > A read-write single value files. The default is "max". > > > @@ -895,6 +897,30 @@ All cgroup core files are prefixed with "cgroup." > > > A dying cgroup can consume system resources not exceeding > > > limits, which were active at the moment of cgroup deletion. > > > > > > + cgroup.freeze > > > + A read-write single value file which exists on non-root cgroups. > > > + Allowed values are "0" and "1". The default is "0". > > > + > > > + Writing "1" to the file causes freezing of the cgroup and all > > > + descendant cgroups. This means that all belonging processes will > > > + be stopped and will not run until the cgroup will be explicitly > > > + unfrozen. Freezing of the cgroup may take some time; when the process > > > > "when the process is complete" sounds somewhat ambiguous, it's unclear > > whether freezing is complete or the process that's being frozen is > > complete. > > > > Maybe "when this action is completed"? > > > > > + is complete, the "frozen" value in the cgroup.events control file > > > + will be updated and the corresponding notification will be issued. > > > > Can you please clarify how exactly cgroup.events would be updated? > > > > > + Cgroup can be frozen either by its own settings, either by settings > > > > ^ A cgroup ... and maybe there are more "a" and "the" that should be > > fixed, it's hard for me to tell. > > > > Also, I believe "either ..., or ..." sounds better than "either ..., > > either ..." > > > > > + of any ancestor cgroups. If any of ancestor cgroups is frozen, the > > > + cgroup will remain frozen. > > > + > > > + Processes in the frozen cgroup can be killed by a fatal signal. > > > + They also can enter and leave a frozen cgroup: either by an explicit > > > + move by a user, either if freezing of the cgroup races with fork(). > > > > ditto > > > > > + If a cgroup is moved to a frozen cgroup, it stops. If a process is > > > > ^ process? > > > > > + moving out of a frozen cgroup, it becomes running. > > > > ^ moved > > Hello, Mike! > > Thanks for the review! I agree with all comments above; fixes queued for v4. > > > > > > + Frozen status of a cgroup doesn't affect any cgroup tree operations: > > > + it's possible to delete a frozen (and empty) cgroup, as well as > > > + create new sub-cgroups. > > > > Maybe it's also worth adding that freezing a process has no effect on its > > memory consumption, at least directly. > > Hm, isn't it the expected behavior? You'd be surprised ;-) Just recently I had a couple of questions about the memory consumption of the frozen processes. > In any case, I assume that cgroup.freeze knob description is not the best place > for a such explanations. Maybe it's better to add a standalone paragraph with > the description of the frozen process state, what's expected to work, what's > not, etc. I'd return to this question a bit later, when we'll agree on the user > interface and the implementation. Sure. > Thanks! > -- Sincerely yours, Mike. ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2018-11-20 14:06 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20181117003830.15344-1-guro@fb.com>
2018-11-17 0:38 ` [PATCH v3 7/7] cgroup: document cgroup v2 freezer interface Roman Gushchin
2018-11-17 8:02 ` Mike Rapoport
2018-11-19 17:42 ` Roman Gushchin
2018-11-20 14:06 ` Mike Rapoport
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).