On Mon, 7 Mar 2011, Andrew Morton wrote: > > So the question I'd ask is > > What about my question? Why is your usersapce oom-handler "unresponsive"? > If we have a per-memcg userspace oom handler, then it's absolutely required that it either increase the hard limit of the oom memcg or kill a task to free memory; anything else risks livelocking that memcg. At the same time, the oom handler's memcg isn't really important: it may be in a different memcg but it may be oom at the same time. If we risk livelocking the memcg when it is oom and the oom killer cannot respond (the only reason for the oom killer to exist in the first place), then there's no guarantee that a userspace oom handler could respond under livelock. For users who don't choose to implement their own userspace oom handler, memory.oom_delay_millisecs could also be used to delay killing a task in a memcg unless it has reached the hard limit for only a specific period of time and doesn't rely on memory thresholds to signal the task to start freeing some of its own memory. -- 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 internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>