> On Fri, 18 Sep 2015, Oleg Nesterov wrote:
> > And btw. Yes, this is a bit off-topic, but I think another change make
> > sense too. We should report the fact we are going to kill another task
> > because the previous victim refuse to die, and print its stack trace.

Thank you for the review and feedback! I think that would definitely be a
nice touch. I would definitely throw my hat in as wanting the above, but in
the interests of keeping things as simple as possible, I kept myself out of
that level of change.

> What happens is that the previous victim did not enter exit processing. If
> it would then it would be excluded by other checks. The first victim never
> reacted and never started using the memory resources available for
> exiting. Thats why I thought it maybe safe to go this way.
>
> An issue could result from another process being terminated and the first
> victim finally reacting to the signal and also beginning termination. Then
> we have contention on the reserves.
>

I do like the idea of not stalling completely in an oom just because the
first attempt didn't go so well. Is there any possibility of simply having
our cake and eating it too? Specifically, omitting TASK_UNINTERRUPTIBLE
tasks
as low-hanging fruit and allowing the oom to continue in the event that the
first attempt stalls?

Just a thought.