On Mon, 7 Mar 2011 19:56:23 -0800 (PST) David Rientjes <rientjes@xxxxxxxxxx> wrote: > On Tue, 8 Mar 2011, KAMEZAWA Hiroyuki wrote: > > > > I was referring specifically to the memcg which a job scheduler or > > > userspace daemon responsible for doing so is attached. If the thread > > > responsible for managing memcgs and increasing limits or killing off lower > > > priority jobs is in a memcg that is oom, there is a chance it will never > > > be able to respond to the condition. > > > > > > > I just think memcg for such daemons shouldn't have any limit or must not > > set oom_disable. I think you know that. So, the question is why you can't > > do it ? Is there special reason which comes from cgroup's characteristics ? > > > > Being in the root memcg doesn't mean the aggregate of your memcg's hard > limits can't exceed the system's memory capacity. > Hmm? That's an unexpected answer. Why system's capacity is problem here ? (root memcg has no 'limit' always.) Is it a problem that 'there is no 'guarantee' or 'private page pool' for daemons ? BTW, if system oom-killer works, memcg's oom_disable is ignored. Why system oom-killer doesn't work ? Thanks, -Kame -- 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>