On Sat 12-06-21 21:46:34, Aaron Tomlin wrote: > Changes since v2: > - Use single character (e.g. 'R' for MMF_OOM_SKIP) as suggested > by Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx> > - Add new header to oom_dump_tasks documentation > > > At the present time, when showing potential OOM victims, we do not > exclude tasks which already have MMF_OOM_SKIP set; it is possible that > the last OOM killable victim was already OOM killed, yet the OOM > reaper failed to reclaim memory and set MMF_OOM_SKIP. > This can be confusing/or perhaps even misleading, to the reader of the > OOM report. Now, we already unconditionally display a task's > oom_score_adj_min value that can be set to OOM_SCORE_ADJ_MIN which is > indicative of an "unkillable" task i.e. is not eligible. 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. Historically, all tasks eligible for the oom killing have been printed. That includes also tasks which are excluded later in the selection. E.g. OOMS_SCORE_ADJ_MIN which can be tricky indeed. IIRC the primary reason was to have a sufficient amount of information to evaluate whether the system is configured properly (e.g. OOMS_SCORE_ADJ_MIN is not used too extensively). More excluded criterion have been added due to implementation details (e.g.MMF_OOM_SKIP or mm shared with otherwise ineligible task. You are correctly pointing out that those internal states are not exposed but you should focus on explanation why that gap really stands in the way for the current upstream. Who is going to consume that information and for what purpose? > This patch provides a clear indication with regard to the OOM > eligibility of each displayed task. This should provide an example of the output with a clarification of the meaning. [...] -- Michal Hocko SUSE Labs
