linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Minchan Kim <minchan.kim@gmail.com>
To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: "Luis Claudio R. Goncalves" <lclaudio@uudg.org>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-mm <linux-mm@kvack.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	David Rientjes <rientjes@google.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	Ingo Molnar <mingo@elte.hu>, Thomas Gleixner <tglx@linutronix.de>,
	Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH 10/11] oom: give the dying task a higher priority
Date: Wed, 30 Jun 2010 23:40:14 +0900	[thread overview]
Message-ID: <20100630144014.GH15644@barrios-desktop> (raw)
In-Reply-To: <20100630183421.AA6B.A69D9226@jp.fujitsu.com>

On Wed, Jun 30, 2010 at 06:35:08PM +0900, KOSAKI Motohiro wrote:
> 
> Sorry, I forgot to cc Luis. resend.
> 
> 
> (intentional full quote)
> 
> > From: Luis Claudio R. Goncalves <lclaudio@uudg.org>
> > 
> > In a system under heavy load it was observed that even after the
> > oom-killer selects a task to die, the task may take a long time to die.
> > 
> > Right after sending a SIGKILL to the task selected by the oom-killer
> > this task has it's priority increased so that it can exit() exit soon,
> > freeing memory. That is accomplished by:
> > 
> >         /*
> >          * We give our sacrificial lamb high priority and access to
> >          * all the memory it needs. That way it should be able to
> >          * exit() and clear out its resources quickly...
> >          */
> >  	p->rt.time_slice = HZ;
> >  	set_tsk_thread_flag(p, TIF_MEMDIE);
> > 
> > It sounds plausible giving the dying task an even higher priority to be
> > sure it will be scheduled sooner and free the desired memory. It was
> > suggested on LKML using SCHED_FIFO:1, the lowest RT priority so that
> > this task won't interfere with any running RT task.
> > 
> > If the dying task is already an RT task, leave it untouched.
> > Another good suggestion, implemented here, was to avoid boosting the
> > dying task priority in case of mem_cgroup OOM.
> > 
> > Signed-off-by: Luis Claudio R. Goncalves <lclaudio@uudg.org>
> > Cc: Minchan Kim <minchan.kim@gmail.com>
> > Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>

Reviewed-by: Minchan Kim <minchan.kim@gmail.com>

It seems code itself doesn't have a problem.
So I give reviewed-by.
But this patch might break fairness of normal process at corner case.
If system working is more important than fairness of processes,
It does make sense. But scheduler guys might have a different opinion.

So at least, we need ACKs of scheduler guys.
Cced Ingo, Peter, Thomas. 

> > ---
> >  mm/oom_kill.c |   34 +++++++++++++++++++++++++++++++---
> >  1 files changed, 31 insertions(+), 3 deletions(-)
> > 
> > diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> > index b5678bf..0858b18 100644
> > --- a/mm/oom_kill.c
> > +++ b/mm/oom_kill.c
> > @@ -82,6 +82,24 @@ static bool has_intersects_mems_allowed(struct task_struct *tsk,
> >  #endif /* CONFIG_NUMA */
> >  
> >  /*
> > + * If this is a system OOM (not a memcg OOM) and the task selected to be
> > + * killed is not already running at high (RT) priorities, speed up the
> > + * recovery by boosting the dying task to the lowest FIFO priority.
> > + * That helps with the recovery and avoids interfering with RT tasks.
> > + */
> > +static void boost_dying_task_prio(struct task_struct *p,
> > +				  struct mem_cgroup *mem)
> > +{
> > +	struct sched_param param = { .sched_priority = 1 };
> > +
> > +	if (mem)
> > +		return;
> > +
> > +	if (!rt_task(p))
> > +		sched_setscheduler_nocheck(p, SCHED_FIFO, &param);
> > +}
> > +
> > +/*
> >   * The process p may have detached its own ->mm while exiting or through
> >   * use_mm(), but one or more of its subthreads may still have a valid
> >   * pointer.  Return p, or any of its subthreads with a valid ->mm, with
> > @@ -421,7 +439,7 @@ static void dump_header(struct task_struct *p, gfp_t gfp_mask, int order,
> >  }
> >  
> >  #define K(x) ((x) << (PAGE_SHIFT-10))
> > -static int oom_kill_task(struct task_struct *p)
> > +static int oom_kill_task(struct task_struct *p, struct mem_cgroup *mem)
> >  {
> >  	p = find_lock_task_mm(p);
> >  	if (!p) {
> > @@ -434,9 +452,17 @@ static int oom_kill_task(struct task_struct *p)
> >  		K(get_mm_counter(p->mm, MM_FILEPAGES)));
> >  	task_unlock(p);
> >  
> > -	p->rt.time_slice = HZ;
> > +
> >  	set_tsk_thread_flag(p, TIF_MEMDIE);
> >  	force_sig(SIGKILL, p);
> > +
> > +	/*
> > +	 * We give our sacrificial lamb high priority and access to
> > +	 * all the memory it needs. That way it should be able to
> > +	 * exit() and clear out its resources quickly...
> > +	 */
> > +	boost_dying_task_prio(p, mem);
> > +
> >  	return 0;
> >  }
> >  #undef K
> > @@ -460,6 +486,7 @@ static int oom_kill_process(struct task_struct *p, gfp_t gfp_mask, int order,
> >  	 */
> >  	if (p->flags & PF_EXITING) {
> >  		set_tsk_thread_flag(p, TIF_MEMDIE);
> > +		boost_dying_task_prio(p, mem);
> >  		return 0;
> >  	}
> >  
> > @@ -489,7 +516,7 @@ static int oom_kill_process(struct task_struct *p, gfp_t gfp_mask, int order,
> >  		}
> >  	} while_each_thread(p, t);
> >  
> > -	return oom_kill_task(victim);
> > +	return oom_kill_task(victim, mem);
> >  }
> >  
> >  /*
> > @@ -670,6 +697,7 @@ void out_of_memory(struct zonelist *zonelist, gfp_t gfp_mask,
> >  	 */
> >  	if (fatal_signal_pending(current)) {
> >  		set_thread_flag(TIF_MEMDIE);
> > +		boost_dying_task_prio(current, NULL);
> >  		return;
> >  	}
> >  
> > -- 
> > 1.6.5.2
> > 
> > 
> > 
> 
> 
> 

-- 
Kind regards,
Minchan Kim

--
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>

  reply	other threads:[~2010-06-30 14:40 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-30  9:25 [mmotm 0611][PATCH 00/11] various OOM bugfixes v3 KOSAKI Motohiro
2010-06-30  9:27 ` [PATCH 01/11] oom: don't try to kill oom_unkillable child KOSAKI Motohiro
2010-06-30  9:27 ` [PATCH 02/11] oom: oom_kill_process() doesn't select kthread child KOSAKI Motohiro
2010-06-30 13:55   ` Minchan Kim
2010-07-01  0:07     ` KOSAKI Motohiro
2010-07-01 13:38       ` Minchan Kim
2010-06-30  9:28 ` [PATCH 03/11] oom: make oom_unkillable_task() helper function KOSAKI Motohiro
2010-06-30 14:19   ` Minchan Kim
2010-07-01  0:07     ` KOSAKI Motohiro
2010-06-30  9:29 ` [PATCH 04/11] oom: oom_kill_process() need to check p is unkillable KOSAKI Motohiro
2010-06-30 13:57   ` Minchan Kim
2010-06-30  9:30 ` [PATCH 05/11] oom: /proc/<pid>/oom_score treat kernel thread honestly KOSAKI Motohiro
2010-06-30 14:03   ` Minchan Kim
2010-07-01  0:07     ` KOSAKI Motohiro
2010-07-01 14:36       ` Minchan Kim
2010-06-30  9:31 ` [PATCH 06/11] oom: kill duplicate OOM_DISABLE check KOSAKI Motohiro
2010-06-30 14:10   ` Minchan Kim
2010-06-30  9:31 ` [PATCH 07/11] oom: move OOM_DISABLE check from oom_kill_task to out_of_memory() KOSAKI Motohiro
2010-06-30 14:20   ` Minchan Kim
2010-07-01  0:07     ` KOSAKI Motohiro
2010-06-30  9:32 ` [PATCH 08/11] oom: cleanup has_intersects_mems_allowed() KOSAKI Motohiro
2010-06-30  9:32 ` [PATCH 09/11] oom: remove child->mm check from oom_kill_process() KOSAKI Motohiro
2010-06-30 14:30   ` Minchan Kim
2010-06-30  9:33 ` [PATCH 10/11] oom: give the dying task a higher priority KOSAKI Motohiro
2010-06-30  9:35   ` KOSAKI Motohiro
2010-06-30 14:40     ` Minchan Kim [this message]
2010-07-02 21:49   ` Andrew Morton
2010-07-06  0:49     ` KOSAKI Motohiro
2010-07-06  0:50       ` [PATCH 1/2] security: add const to security_task_setscheduler() KOSAKI Motohiro
2010-07-06  0:51       ` [PATCH 2/2] sched: make sched_param arugment static variables in some sched_setscheduler() caller KOSAKI Motohiro
2010-07-06 22:13         ` Steven Rostedt
2010-07-06 23:12           ` Andrew Morton
2010-07-06 23:49             ` Steven Rostedt
2010-07-07  0:02               ` Andrew Morton
2010-07-07 19:43                 ` Peter Zijlstra
2010-06-30  9:34 ` [PATCH 11/11] oom: multi threaded process coredump don't make deadlock KOSAKI Motohiro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100630144014.GH15644@barrios-desktop \
    --to=minchan.kim@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=lclaudio@uudg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.org \
    --cc=rientjes@google.com \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox