On Tue 15-06-21 12:51:47, Aaron Tomlin wrote: > On Mon 2021-06-14 08:44 +0200, Michal Hocko wrote: > > Well, I have to say that I have a bit hard time understand the problem > > statement here. First of all you are very likely basing your observation > > on an old kernel which is missing a fix which should make the situation > > impossible IIRC. You should be focusing on a justification why the new > > information is helpful for the current tree. > > Michal, > > Not exactly. > > See oom_reap_task(). Let's assume an OOM event occurred within the context > of a memcg and 'memory.oom.group' was not set. If I understand correctly, > once all attempts to OOM reap the specified task were "unsuccessful" then > MMF_OOM_SKIP is applied; and, the assumption is it will be terminated > shorty due to the pending fatal signal (see __oom_kill_process()) i.e. a > SIGKILL is sent to the "victim" before the OOM reaper is notified. Now > assuming the above task did not exited yet, another task, in the same > memcg, could also trigger an OOM event. Therefore, when showing potential > OOM victims the task above with MMF_OOM_SKIP set, will indeed be displayed. > > I understanding the point on OOM_SCORE_ADJ_MIN. This can be easily > identified and is clear to the viewer. However, the same cannot be stated > for MMF_OOM_SKIP. This is all true but it is not really clear why that is really a problem. Kernel log already contains information about reaped processes as they are reported to the log. I fully acknowledge that this is rather spartan but on the other hand from years of experience reading oom reports I have to say the dump_tasks is the least interesting part of the report (while being the most verbose one). All that being said, I am not really opposing extending the information although I am a bit worried about leaking too much internal state to the log. What I am asking for here is a justification why this addition is a general improvement and how it helps uderstanding oom reports further. So please focus on that part. -- Michal Hocko SUSE Labs
