On 2017/05/23 20:05, Konstantin Khlebnikov wrote: > On 23.05.2017 10:27, Michal Hocko wrote: >> On Fri 19-05-17 17:22:30, Konstantin Khlebnikov wrote: >>> Show count of global oom killer invocations in /proc/vmstat and >>> count of oom kills inside memory cgroup in knob "memory.events" >>> (in memory.oom_control for v1 cgroup). >>> >>> Also describe difference between "oom" and "oom_kill" in memory >>> cgroup documentation. Currently oom in memory cgroup kills tasks >>> iff shortage has happened inside page fault. >>> >>> These counters helps in monitoring oom kills - for now >>> the only way is grepping for magic words in kernel log. >> >> Have you considered adding memcg's oom alternative for the global case >> as well. It would be useful to see how many times we hit the OOM >> condition without killing anything. That could help debugging issues >> when the OOM killer cannot be invoked (e.g. GFP_NO{FS,IO} contextx) >> and the system cannot get out of the oom situation. > > I think present warn_alloc() should be enough for debugging, > maybe it should taint kernel in some cases to give a hint for future warnings/bugs. > I don't think warn_alloc() is enough. We can fail to warn using warn_alloc(), see http://lkml.kernel.org/r/1495331504-12480-1-git-send-email-penguin-kernel@xxxxxxxxxxxxxxxxxxx . -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html