Re: [PATCH 3/3] memcg oom: bail out from the charge path if no victim found

[Michal Hocko <mhocko@kernel.org>]

On Sat 18-04-20 11:13:11, Yafang Shao wrote:
> Without considering the manually triggered OOM, if no victim found in
> system OOM, the system will be deadlocked on memory, however if no
> victim found in memcg OOM, it can charge successfully and runs well.
> This behavior in memcg oom is not proper because that can prevent the
> memcg from being limited.
> 
> Take an easy example.
>         $ cd /sys/fs/cgroup/foo/
> 	$ echo $$ > cgroup.procs
> 	$ echo 200M > memory.max
> 	$ cat memory.max
> 	209715200
> 	$ echo -1000 > /proc/$$/oom_score_adj
> Then, let's run a memhog task in memcg foo, which will allocate 1G
> memory and keeps running.
> 	$ /home/yafang/test/memhog &

Well, echo -1000 is a privileged operation. And it has to be used with
an extreme care because you know that you are creating an unkillable
task. So the above test is a clear example of the misconfiguration.

> Then memory.current will be greater than memory.max. Run bellow command
> in another shell.
> 	$ cat /sys/fs/cgroup/foo/memory.current
> 	1097228288
> The tasks which have already allocated memory and won't allocate new
> memory still runs well. This behavior makes nonsense.
> 
> This patch is to improve it.
> If no victim found in memcg oom, we should force the current task to
> wait until there's available pages. That is similar with the behavior in
> memcg1 when oom_kill_disable is set.

The primary reason why we force the charge is because we _cannot_ wait
indefinitely in the charge path because the current call chain might
hold locks or other resources which could block a large part of the
system. You are essentially reintroducing that behavior.

Is the above example a real usecase or you have just tried a test case
that would trigger the problem?
-- 
Michal Hocko
SUSE Labs