On Fri 03-10-14 11:03:30, Cong Wang wrote:

On Fri, Oct 3, 2014 at 8:13 AM, Michal Hocko [off-list ref] wrote:

quoted

That commit fixes an OOM deadlock. Not a soft lockup. Do you have the
OOM killer report from the log? This would tell us that the killed task
was indeed sleeping on the lock which is hold by the charger which
triggered the OOM. I am little bit surprised that I do not see any OOM
related functions on the stacks (maybe the code is inlined...).

Oh, did you see __mem_cgroup_try_charge() calls
schedule_timeout_uninterruptible() in stack trace? Yes, they are inlined
and I don't see any other possibilities for calling it.

Yes the only place we call schedule_timeout_uninterruptible from is
mem_cgroup_handle_oom. And it happens only for a task which hasn't been
killed by OOM killer.

quoted

It would be better to know what exactly is going on before backporting
this change because it is quite large.

I thought the stack trace I showed is obvious. :) I am very happy
to investigate if you see any other path calling
schedule_timeout_uninterruptible()
in __mem_cgroup_try_charge().

I was expecting an oom report which kills a task which is sleeping on a
lock which is held on the way up to the charge function. Your report
mentioned a task waiting for i_mutex for too long. It is true that the
charging path is holding an i_mutex as well so it might be the same
situation handled by the said patch. But it is not 100% clear this is
the case without an OOM report which would point to the waiting task.
The memcg might be trashing on the hard limit and reclaim might take a
long time.

-- 
Michal Hocko
SUSE Labs