On Fri, 7 May 2010 14:30:21 -0700 Jeremy Hanmer <jeremy@xxxxxxxxxxxxxxx> wrote: > I've found a reproducible case where you can create an infinite loop inside the oom killer if you create a cgroup with a single process that has oom_adj=-17 and trigger an OOM situation inside that cgroup. > > It seems that oom_adj should probably be ignored in the case where it makes the OOM situation unsolvable. Here's an excerpt from the console output when the bug is triggered: > > Memory cgroup out of memory: kill process 25306 (memeater) score 0 or a child > Memory cgroup out of memory: kill process 25306 (memeater) score 0 or a child > Memory cgroup out of memory: kill process 25306 (memeater) score 0 or a child > Memory cgroup out of memory: kill process 25306 (memeater) score 0 or a child > Memory cgroup out of memory: kill process 25306 (memeater) score 0 or a child > Memory cgroup out of memory: kill process 25306 (memeater) score 0 or a child > Memory cgroup out of memory: kill process 25306 (memeater) score 0 or a child > Memory cgroup out of memory: kill process 25306 (memeater) score 0 or a child > Memory cgroup out of memory: kill process 25306 (memeater) score 0 or a child > Memory cgroup out of memory: kill process 25306 (memeater) score 0 or a child > Memory cgroup out of memory: kill process 25306 (memeater) score 0 or a child > Memory cgroup out of memory: kill process 25306 (memeater) score 0 or a child > Now, In -mm tree, 2 options are supproted and it's under test. 1. oom_notifier ... an event notifier which notifies OOM. 2. oom_disable ... disable OOM-Killer. All threads will wait for the end of OOM. No cpu consumption. By 1+2, an user(user-land deamon) can implement its own OOM handler. Please wait it. Thanks, -Kame _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers