On Wed, 22 Dec 2010, KAMEZAWA Hiroyuki wrote: > For example. oom_check_deadlockd can work as > > 1. disable oom by memory.oom_disable=1 > 2. check memory.oom_notify and wait it by poll() > 3. At oom, it wakes up. > 4. wait for 60 secs. > 5. If the cgroup is still in OOM, set oom_disalble=0 > > This daemon will not use much memory and can run in /roog memory cgroup. > Yes, this is almost the same as the "simple and perfect implementation" that I eluded to in my response to Andrew (and I think KOSAKI-san suggested something similiar), although it doesn't quite work because all threads in the cgroup are sitting on the waitqueue and don't get woken up to see oom_control == 0 unless memory is freed, a task is moved, or the limit is resized so this daemon will need to trigger that as step #6. That certainly works if it is indeed perfect and guaranteed to always be running. In the interest of a robust resource isolation model, I don't think we can ever make that conclusion, though, so this discussion is really only about how fault tolerant the kernel is because the end result is if this daemon fails, the kernel livelocks. I'd personally prefer not to allow a buggy or imperfect userspace to allow the kernel to livelock; we control the kernel so I think it would be best to ensure that it cannot livelock no matter what userspace happens to do despite its best effort. If you or Andrew come to the conclusion that it's overkill and at the end of the day we have to trust userspace, I really can't argue that philosophy though :) -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>