On Mon, Jul 20, 2020 at 7:06 PM Tetsuo Handa
<penguin-kernel@xxxxxxxxxxxxxxxxxxx> wrote:
>
> On 2020/07/20 19:36, Yafang Shao wrote:
> > On Mon, Jul 20, 2020 at 3:16 PM Michal Hocko <mhocko@xxxxxxxxxx> wrote:
> >> I do agree that a silent bail out is not the best thing to do. The above
> >> message would be more useful if it also explained what the oom killer
> >> does (or does not):
> >>
> >> "OOM victim %d (%s) is already exiting. Skip killing the task\n"
> >>
> >
> > Sure.
>
> This path is rarely hit because find_lock_task_mm() in oom_badness() from
> select_bad_process() in the next round of OOM killer will skip this task.
>
> 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.
>
Could you pls. explain more specifically why we will get two chunks of
dump_header()?
My understanding is the free_mm() happens between select_bad_process()
and __oom_kill_process() as bellow,
P1
Victim
select_bad_process()
oom_badness()
p = find_lock_task_mm() # p isn't NULL
__mmput()
free_mm()
dump_header() # dump once
__oom_kill_process()
p = find_lock_task_mm(victim); # p is NULL now
So where is another dump_header() ?
> 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?
--
Thanks
Yafang
