Tetsuo Handa
from-****@I-lov*****
Sat Feb 5 23:44:09 JST 2011
Jamie Nguyen wrote: > I should also mention that the memory usage jumps up almost instantly. > It goes from a small amount suddenly to 3GB. Thank you. I built vanilla 2.6.37 using your kernel config on CentOS 5.5. I noticed that the same audit log appear for many times when I did "cat /proc/ccs/*". Maybe a problem has occurred while reading /proc/ccs/ interface. #2011/02/05 22:30:33# profile=1 mode=learning granted=no (global-pid=56) task={ pid=56 ppid=55 uid=0 gid=0 euid=0 egid=0 suid=0 sgid=0 fsuid=0 fsgid=0 type!=execute_handler } path1={ uid=0 gid=0 ino=1835522 major=8 minor=1 perm=0755 type=file } path1.parent={ uid=0 gid=0 ino=1835521 perm=0755 } exec={ realpath="/usr/libexec/gcc/x86_64-redhat-linux/4.1.1/cc1" argc=15 envc=12 argv[]={ "/usr/libexec/gcc/x86_64-redhat-linux/4.1.2/cc1" "-quiet" "-iprefix" "../lib/gcc/x86_64-redhat-linux/4.1.2/" "ccs_bind_test.c" "-quiet" "-dumpbase" "ccs_bind_test.c" "-mtune=generic" "-auxbase" "ccs_bind_test" "-O2" "-Wall" "-o" "/tmp/ccGBPUuJ.s" } envp[]={ "_=/usr/bin/make" "PWD=/root/ccstools/kernel_test" "HOME=/" "SHLVL=1" "OLDPWD=/root/ccstools" "MAKEFLAGS=" "MFLAGS=" "TERM=linux" "MAKELEVEL=1" "COLLECT_GCC=gcc" "GCC_EXEC_PREFIX=../lib/gcc/" "COLLECT_GCC_OPTIONS='-Wall'\040'-O2'\040'-o'\040'ccs_bind_test'\040'-mtune=generic'" } } <kernel> /usr/bin/make /usr/bin/gcc /usr/libexec/gcc/x86_64-redhat-linux/4.1.1/cc1 misc env SHLVL #2011/02/05 22:30:33# profile=1 mode=learning granted=no (global-pid=56) task={ pid=56 ppid=55 uid=0 gid=0 euid=0 egid=0 suid=0 sgid=0 fsuid=0 fsgid=0 type!=execute_handler } path1={ uid=0 gid=0 ino=1835522 major=8 minor=1 perm=0755 type=file } path1.parent={ uid=0 gid=0 ino=1835521 perm=0755 } exec={ realpath="/usr/libexec/gcc/x86_64-redhat-linux/4.1.1/cc1" argc=15 envc=12 argv[]={ "/usr/libexec/gcc/x86_64-redhat-linux/4.1.2/cc1" "-quiet" "-iprefix" "../lib/gcc/x86_64-redhat-linux/4.1.2/" "ccs_bind_test.c" "-quiet" "-dumpbase" "ccs_bind_test.c" "-mtune=generic" "-auxbase" "ccs_bind_test" "-O2" "-Wall" "-o" "/tmp/ccGBPUuJ.s" } envp[]={ "_=/usr/bin/make" "PWD=/root/ccstools/kernel_test" "HOME=/" "SHLVL=1" "OLDPWD=/root/ccstools" "MAKEFLAGS=" "MFLAGS=" "TERM=linux" "MAKELEVEL=1" "COLLECT_GCC=gcc" "GCC_EXEC_PREFIX=../lib/gcc/" "COLLECT_GCC_OPTIONS='-Wall'\040'-O2'\040'-o'\040'ccs_bind_test'\040'-mtune=generic'" } } <kernel> /usr/bin/make /usr/bin/gcc /usr/libexec/gcc/x86_64-redhat-linux/4.1.1/cc1 misc env SHLVL Audit logs should be removed from the kernel memory when read() via /proc/ccs/audit interface. ccs_write_log2() adds an audit log and ccs_read_log() removes that audit log. These operations are protected by ccs_log_lock spinlock. spin_lock(&ccs_log_lock); list_add_tail(&entry->list, &ccs_log); spin_unlock(&ccs_log_lock); spin_lock(&ccs_log_lock); list_del(&ptr->list); spin_unlock(&ccs_log_lock); But above output suggests that the audit log was not removed by some reason. Then, next suspicious part would be ccs_flush(). I'm reading it now. If the problem you encountered is that ccs-editpolicy continues adding entries because the kernel has fallen into infinite reading loop while reading /proc/ccs/domain_policy or /proc/ccs/exception_policy , it is natural that ccs-editpolicy consumes system's all memory and consumes some of CPU time. Regards.