On Mon, Oct 22, 2012 at 7:46 AM, Qiang Gao <gaoqiangscut@xxxxxxxxx> wrote: > I don't know whether the process will exit finally, bug this stack lasts > for hours, which is obviously unnormal. > The situation: we use a command calld "cglimit" to fork-and-exec the worker > process,and the "cglimit" will > set some limitation on the worker with cgroup. for now,we limit the > memory,and we also use cpu cgroup,but with > no limiation,so when the worker is running, the cgroup directory looks like > following: > > /cgroup/memory/worker : this directory limit the memory > /cgroup/cpu/worker :with no limit,but worker process is in. > > for some reason(some other process we didn't consider), the worker process > invoke global oom-killer, > not cgroup-oom-killer. then the worker process hangs there. > > Actually, if we didn't set the worker process into the cpu cgroup, this will > never happens. > You said you don't use CPU limits right? can you also send in the output of /proc/sched_debug. Can you also send in your /etc/cgconfig.conf? If the OOM is not caused by cgroup memory limit and the global system is under pressure in 2.6.32, it can trigger an OOM. Also 1. Have you turned off swapping (seems like it) right? 2. Do you have a NUMA policy setup for this task? Can you also share the .config (not sure if any special patches are being used) in the version you've mentioned. Balbir -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>