Michal Hocko wrote:
> On Thu 17-03-16 19:49:01, Tetsuo Handa wrote:
> [...]
> > diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> > index 2199c71..affbb79 100644
> > --- a/mm/oom_kill.c
> > +++ b/mm/oom_kill.c
> > @@ -502,8 +502,26 @@ static void oom_reap_vmas(struct mm_struct *mm)
> > schedule_timeout_idle(HZ/10);
> >
> > if (attempts > MAX_OOM_REAP_RETRIES) {
> > + struct task_struct *p;
> > + struct task_struct *t;
> > +
> > pr_info("oom_reaper: unable to reap memory\n");
> > - debug_show_all_locks();
> > + rcu_read_lock();
> > + for_each_process_thread(p, t) {
> > + if (likely(t->mm != mm))
> > + continue;
> > + pr_info("oom_reaper: %s(%u) flags=0x%x%s%s%s%s\n",
> > + t->comm, t->pid, t->flags,
> > + (t->state & TASK_UNINTERRUPTIBLE) ?
> > + " uninterruptible" : "",
> > + (t->flags & PF_EXITING) ? " exiting" : "",
> > + fatal_signal_pending(t) ? " dying" : "",
> > + test_tsk_thread_flag(t, TIF_MEMDIE) ?
> > + " victim" : "");
> > + sched_show_task(t);
> > + debug_show_held_locks(t);
> > + }
> > + rcu_read_unlock();
>
> Isn't this way too much work for a single RCU lock? Also wouldn't it
> generate way too much output in the pathological situations a so hide
> other potentially more important log messages?
>
I don't think we can compare it. It is possible that 50 out of 10000
threads' traces and locks are reported with this change, but it is also
possible that 10000 threads' locks are reported without this change.
If you worry about too much work for a single RCU, you can do like
what kmallocwd does. kmallocwd adds a marker to task_struct so that
kmallocwd can reliably resume reporting.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>