On 27.11.19 12:41, Michal Hocko wrote:
> On Wed 27-11-19 12:11:24, David Hildenbrand wrote:
> [...]
>> 4. This patch on its own (if there are no processes, there is nothing to
>> kill) does not sound too wrong to me. Instead of an endless loop
>> (besides signals) where we can't make any progress, we exit right away.
>
> mem_cgroup_out_of_memory returns false when there is no oom victim
> selected and then we break out.
I see. So it really is one iteration of OOM messages and then we break.
>
> My main objection to the patch is that it adds a subtle inconsitency.
> Admins are simply not going to see that the memcg was OOM due to the
> limit change and OOM killer cannot do anything about that. No tasks vs.
> no killable task doesn't make any real difference. There is simply no
> way to get out of that situation.
Yeah, I was asking myself if we could handle that differently in the
shrinker then. E.g., print a different message ("OOM but no killable
tasks") or sth. like that. The the admin is aware that there is an OOM
event and that e.g., starting the next process will definitely result in
surprises.
But again, no expert :)
--
Thanks,
David / dhildenb
