Re: [PATCH 6/5] oom, oom_reaper: disable oom_reaper for oom_kill_allocating_task

[Michal Hocko <mhocko@kernel.org>]

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?

-- 
Michal Hocko
SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>