When system contains cgrules.conf file with few thousand rules,
cgroup_change_cgroup_flags() function without CGFLAG_USECACHE flag is very slow.
As Ivana pointed out, cgexec and cgclassify tools might have problems with cache
reloading, so I've removed them from the patch for now.
Currently, the patch affects only cgrulesengd daemon. Testing was done with
approximately 4000 users, rules in cgrules.conf file and same amount of entries
in cgconfig.conf. Without the CGFLAG_USECACHE the cgrulesengd is starting for
about 15 - 20 minutes (this is because of cgroup_change_all_cgroups() function,
which scans all running processes on cgrulesengd start).
Signed-off-by: Peter Schiffer <pschi...@redhat.com>
---
src/api.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/api.c b/src/api.c
index b8bbf9b..edc3f8b 100644
--- a/src/api.c
+++ b/src/api.c
@@ -3125,7 +3125,8 @@ int cgroup_change_all_cgroups(void)
if (err)
continue;
- err = cgroup_change_cgroup_flags(euid, egid, procname, pid, 0);
+ err = cgroup_change_cgroup_flags(euid,
+ egid, procname, pid, CGFLAG_USECACHE);
if (err)
cgroup_dbg("cgroup change pid %i failed\n", pid);
}
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
_______________________________________________
Libcg-devel mailing list
Libcg-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libcg-devel
