On Mon 20-07-20 23:03:46, Tetsuo Handa wrote: > 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 . As soon as we learn about more of those as mentioned above. -- Michal Hocko SUSE Labs
