On Thu, 10 Mar 2011, Oleg Nesterov wrote:
> --- 38/mm/oom_kill.c~oom_kill_spread_memdie 2011-03-08 14:45:49.000000000 +0100
> +++ 38/mm/oom_kill.c 2011-03-10 16:08:51.000000000 +0100
> @@ -401,6 +401,17 @@ static void dump_header(struct task_stru
> dump_tasks(mem, nodemask);
> }
>
> +static void do_oom_kill(struct task_struct *p)
> +{
> + struct task_struct *t;
> +
> + do {
> + set_tsk_thread_flag(t, TIF_MEMDIE);
> + } while_each_thread(p, t);
> +
> + force_sig(SIGKILL, p);
> +}
> +
> #define K(x) ((x) << (PAGE_SHIFT-10))
> static int oom_kill_task(struct task_struct *p, struct mem_cgroup *mem)
> {
> @@ -436,12 +447,10 @@ static int oom_kill_task(struct task_str
> pr_err("Kill process %d (%s) sharing same memory\n",
> task_pid_nr(q), q->comm);
> task_unlock(q);
> - force_sig(SIGKILL, q);
> + do_oom_kill(q);
> }
>
> - set_tsk_thread_flag(p, TIF_MEMDIE);
> - force_sig(SIGKILL, p);
> -
> + do_oom_kill(p);
> /*
> * We give our sacrificial lamb high priority and access to
> * all the memory it needs. That way it should be able to
>
>
This isn't appropriate: we specifically try to limit TIF_MEMDIE to only
threads that need it (those that need it in the exit path), otherwise we
risk completely depleting all memory, which would result in an oom
deadlock. TIF_MEMDIE isn't supposed to be used as a flag to detect oom
killed task despite its use in select_bad_process() -- if a thread needs
access to memory reserves after receiving a SIGKILL then out_of_memory()
provides that appropriately.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxxx For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>