On Fri, Jun 7, 2019 at 8:53 AM Michal Koutný <mkou...@suse.com> wrote: > > 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. >
I agree. cgred was always racy, it was always best effort. I will add this in to reduce the window. Thanks Michal! Dhaval _______________________________________________ Libcg-devel mailing list Libcg-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libcg-devel
