Hello. On Fri, Apr 23, 2021 at 12:01:38PM -0700, Roman Gushchin <guro@xxxxxx> 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:
signature.asc
Description: Digital signature
