Re: [PATCH] mm, oom: show process exiting information in __oom_kill_process()

[Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>]

On 2020/07/20 22:41, Michal Hocko wrote:
>> Since we don't wake up the OOM reaper when hitting this path, unless __mmput()
>> for this task itself immediately reclaims memory and updates the statistics
>> counter, we just get two chunks of dump_header() messages and one OOM victim.
>>
>> Current synchronous printk() gives __mmput() some time for reclaiming memory
>> and updating the statistics counter. But when printk() becomes asynchronous,
>> there might be quite small time. People might wonder "why killed message
>> follows immediately after skipped killing message"... Wouldn't the skip
>> message confuse people?
> 
> I would ask other way around. Wouldn't that give us a better clue that
> the first oom invocation and the back off was a suboptimal decision? If
> we learn about more of those, maybe we want to reconsider this heuristic
> and rather retry the victim selection instead.

I've just suggested

  Maybe the better behavior is to restart out_of_memory() without dump_header()
  (we can remember whether we already called dump_header() into "struct oom_control"),
  with last second watermark check before select_bad_process() and after dump_header().

at https://lkml.kernel.org/r/7f58363a-db1a-5502-e2b4-ee4b9fa31824@i-love.sakura.ne.jp .