>Unfortunately I am not able to reproduce this behavior even if I try >to hammer OOM like mad so I am afraid I cannot help you much without >further debugging patches. >I do realize that experimenting in your environment is a problem but I >do not many options left. Please do not use strace and rather collect >/proc/pid/stack instead. It would be also helpful to get group/tasks >file to have a full list of tasks in the group Sending new info! I found out one interesting thing. When problem occurs (it probably happen when OOM is started in target cgroup but i'm not sure), the target cgroup, somehow, becames broken. In other words, after the problem occurs once in target cgroup, it is happening always in this cgroup. I made this test: 1.) I create cgroup A with limits (also with memory limit). 2.) Waited when OOM is started (can takes hours). Processes in target cgroup becames freezed so they must be killed. 3.) After this, processes are always freezing in cgroup A, it usually takes 20-30 seconds after killing previously freezed processes. 4.) I created cgroup B with the *same* limits as cgroup A and moved user from A to B. Problem disappears. 5.) Go to (2) And second thing, i got've kernel oops, look at the end of: http://watchdog.sk/lkml/oops -- 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>