On Mon, 7 Mar 2011 17:18:53 -0800 Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > On Mon, 7 Mar 2011 17:02:36 -0800 (PST) > David Rientjes <rientjes@xxxxxxxxxx> wrote: > > Keep in mind that for oom situations we give the killed > > task access to memory reserves below the min watermark with TIF_MEMDIE so > > that they can allocate memory to exit as quickly as possible (either to > > handle the SIGKILL or within the exit path). That's because we can't > > guarantee anything within an oom system, cpuset, mempolicy, or memcg is > > ever responsive without it. (And, the side effect of it and its threads > > exiting is the freeing of memory which allows everything else to once > > again be responsive.) > > > > > That this is the only situation you've observed in which the > > > userspace oom-handler is "unresponsive"? > > > > > > > Personally, yes, but I could imagine other users could get caught if their > > userspace oom handler requires taking locks (such as mmap_sem) by reading > > within procfs that a thread within an oom memcg already holds. > > If activity in one memcg cause a lockup of processes in a separate > memcg then that's a containment violation and we should fix it. > I hope dirty_ratio + async I/O controller will can be a help.. cpu controller is an only help for now (for limiting time for vmscan) I'm not sure what we need other than above for now. > One could argue that peering into a separate memcg's procfs files was > already a containment violation, but from a practical point of view we > definitely do want processes in a separate memcg to be able to > passively observe activity in another without stepping on lindmines. > It's namespace job, I think. 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>