Re: [RFC PATCH] cgroup: add cgroup.signal

["Michal Koutný" <mkoutny-IBi9RG/b67k@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 1162 bytes --]

Hello.

On Fri, Apr 23, 2021 at 12:01:38PM -0700, Roman Gushchin <guro-b10kYP2dOMg@public.gmane.org> wrote:
> Overall it sounds very reasonable and makes total sense to me.
I agree this sounds like very desired convenience...

> Many userspace applications can use the new interface instead of
> reading cgroup.procs in a cycle and killing all processes or using the
> freezer and kill a frozen list of tasks.
...however, exactly because of this, I'm not convinced it's justifying
yet another way how to do it and implement that in kernel. (AFAIU, both
those ways should be reliable too (assuming reading cgroup.procs of the
_default_ hierarchy), please correct me if I'm wrong.)

> It will simplify the code and make it more reliable.
It's not cost free though, part of the complexity is moved to the
kernel.
As Roman already pointed earlier, there are is unclear situation wrt
forking tasks. The similar had to be solved for the freezer hence why
not let uspace rely on that already? Having similar codepaths for
signalling the cgroups seems like a way to have two similar codepaths
side by side where one of them serves just to simplify uspace tools.

Michal

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]