Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1697119

Re: [v4 1/4] mm, oom: refactor the TIF_MEMDIE usage

From Michal Hocko <mhocko@kernel.org>
Newsgroups linux.kernel
Subject Re: [v4 1/4] mm, oom: refactor the TIF_MEMDIE usage
Date 2017-07-26 16:00 +0200
Message-ID <u7v0Z-11L-7@gated-at.bofh.it> (permalink)
References <u7v0Z-11L-9@gated-at.bofh.it> <u7v0Z-11L-11@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Wed 26-07-17 14:27:15, Roman Gushchin wrote:
[...]
> @@ -656,13 +658,24 @@ static void mark_oom_victim(struct task_struct *tsk)
>  	struct mm_struct *mm = tsk->mm;
>  
>  	WARN_ON(oom_killer_disabled);
> -	/* OOM killer might race with memcg OOM */
> -	if (test_and_set_tsk_thread_flag(tsk, TIF_MEMDIE))
> +
> +	if (!cmpxchg(&tif_memdie_owner, NULL, current)) {
> +		struct task_struct *t;
> +
> +		rcu_read_lock();
> +		for_each_thread(current, t)
> +			set_tsk_thread_flag(t, TIF_MEMDIE);
> +		rcu_read_unlock();
> +	}

I would realy much rather see we limit the amount of memory reserves oom
victims can consume rather than build on top of the current hackish
approach of limiting the number of tasks because the fundamental problem
is still there (a heavy multithreaded process can still deplete the
reserves completely).

Is there really any reason to not go with the existing patch I've
pointed to the last time around? You didn't seem to have any objects
back then.
-- 
Michal Hocko
SUSE Labs

Back to linux.kernel | Previous | Next — Next in thread | Find similar | Unroll thread


Thread

Re: [v4 1/4] mm, oom: refactor the TIF_MEMDIE usage Michal Hocko <mhocko@kernel.org> - 2017-07-26 16:00 +0200
  Re: [v4 1/4] mm, oom: refactor the TIF_MEMDIE usage Michal Hocko <mhocko@kernel.org> - 2017-07-26 16:30 +0200
    Re: [v4 1/4] mm, oom: refactor the TIF_MEMDIE usage Michal Hocko <mhocko@kernel.org> - 2017-07-26 16:50 +0200

csiph-web