On Thu, Jan 22, 2009 at 5:21 AM, Evgeniy Polyakov <zbr@xxxxxxxxxxx> wrote: > Having userspace to decide which task to kill may not work in some cases > at all (when task is swapped and we need to kill someone to get the mem > to swap out the task, which will make that decision). That's true in the case of a global OOM. In the case of a local OOM (caused by memory limits applied via the cgroup memory controller, or NUMA affinity enforcement applied by cpusets) the userspace handler can be in a different domain which isn't OOM, and be quite capable of figuring out who to kill. In our particular use case, it can happen that a high-priority job hits its memory limits and triggers an OOM, which causes the system controller daemon to kill some lower-priority job and reassign some memory from that now-dead low-priority job (and thus prevent the OOM from killing any process in the original cgroup). This is something that would be very hard to express via kernel policy. Paul _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
