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. > > So you're saying that your userspace oom-handler is in a memcg which is > also oom? It could be, if users assign the handler to a different memcg; otherwise, it's guaranteed. 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. -- 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>