On Fri, Jun 07, 2019 at 09:12:30AM -0600, Tom Hromatka <tom.hroma...@oracle.com> wrote: > The v2 patch definitely improved the race condition, but I was still > able to "confuse" cgrulesengd on my system by setting its niceness to > 19 _and_ compiling the linux kernel at the same time. In this > highly-loaded scenario, the test program was not assigned to the testcgroup > and rather fell into /user.slice. The test loop breaks when it doesn't see process in correct cgroups in given timeout. With the higher load, the test may stop but later look at cgroups would be correct. If not, the patch does not strive to cover all forking patterns (as I find that impossible because the reasoning below).
> I would like to hear others' thoughts - especially if it's possible to > fully resolve the race condition, but I think this patch is an improvement > over the current code. I'm not others :-) but I'd like to share my opinion -- cgred can only provide some best effort guarantees. Since we we have no control over the new process's execution (CN_IDX_PROC does passive notifation about a new process), it can do whatever it wants _before_ cgred gets down to migrate it to proper cgroup and it may already be in a state that wouldn't be allowed in the target cgroup (memory over limit, affine to particular CPU or have children in another cgroup). Michal _______________________________________________ Libcg-devel mailing list Libcg-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libcg-devel
