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@xxxxxxxxxxxxxxxxxxx .
