On Mon, 7 Mar 2011, Andrew Morton wrote:

quoted

quoted

quoted

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@kvack.org.  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@kvack.org"> email@kvack.org </a>