oom-kill: give the dying task a higher priority
in [Kernel]
|
Prev: [RFC] oom-kill: give the dying task a higher priority
Next: [PATCH 1/2 v2] FLAT: split the stack & data alignments
From: Minchan Kim on 28 May 2010 01:40 Hi, Kosaki. On Fri, May 28, 2010 at 1:46 PM, KOSAKI Motohiro <kosaki.motohiro(a)jp.fujitsu.com> wrote: >> * Luis Claudio R. Goncalves <lclaudio(a)uudg.org> [2010-05-28 00:51:47]: >> >> > @@ -382,6 +382,8 @@ static void dump_header(struct task_struct *p, gfp_t gfp_mask, int order, >> > */ >> > static void __oom_kill_task(struct task_struct *p, int verbose) >> > { >> > + struct sched_param param; >> > + >> > if (is_global_init(p)) { >> > WARN_ON(1); >> > printk(KERN_WARNING "tried to kill init!\n"); >> > @@ -413,8 +415,9 @@ static void __oom_kill_task(struct task_struct *p, int verbose) >> > */ >> > p->rt.time_slice = HZ; >> > set_tsk_thread_flag(p, TIF_MEMDIE); >> > - >> > force_sig(SIGKILL, p); >> > + param.sched_priority = MAX_RT_PRIO-1; >> > + sched_setscheduler_nocheck(p, SCHED_FIFO, ¶m); >> > } >> > >> >> I would like to understand the visible benefits of this patch. Have >> you seen an OOM kill tasked really get bogged down. Should this task >> really be competing with other important tasks for run time? > > What you mean important? Until OOM victim task exit completely, the system have no memory. > all of important task can't do anything. > > In almost kernel subsystems, automatically priority boost is really bad idea because > it may break RT task's deterministic behavior. but OOM is one of exception. The deterministic > was alread broken by memory starvation. Yes or No. IMHO, normally RT tasks shouldn't use dynamic allocation(ie, non-deterministic functions or system calls) in place which is needed deterministic. So memory starvation might not break real-time deterministic. > > That's the reason I acked it. > > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo(a)kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: <a href=mailto:"dont(a)kvack.org"> email(a)kvack.org </a> > -- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: KOSAKI Motohiro on 28 May 2010 01:40 Hi > Hi, Kosaki. > > On Fri, May 28, 2010 at 1:46 PM, KOSAKI Motohiro > <kosaki.motohiro(a)jp.fujitsu.com> wrote: > >> * Luis Claudio R. Goncalves <lclaudio(a)uudg.org> [2010-05-28 00:51:47]: > >> > >> > @@ -382,6 +382,8 @@ static void dump_header(struct task_struct *p, gfp_t gfp_mask, int order, > >> > */ > >> > static void __oom_kill_task(struct task_struct *p, int verbose) > >> > { > >> > + struct sched_param param; > >> > + > >> > if (is_global_init(p)) { > >> > WARN_ON(1); > >> > printk(KERN_WARNING "tried to kill init!\n"); > >> > @@ -413,8 +415,9 @@ static void __oom_kill_task(struct task_struct *p, int verbose) > >> > */ > >> > p->rt.time_slice = HZ; > >> > set_tsk_thread_flag(p, TIF_MEMDIE); > >> > - > >> > force_sig(SIGKILL, p); > >> > + param.sched_priority = MAX_RT_PRIO-1; > >> > + sched_setscheduler_nocheck(p, SCHED_FIFO, ¶m); > >> > } > >> > > >> > >> I would like to understand the visible benefits of this patch. Have > >> you seen an OOM kill tasked really get bogged down. Should this task > >> really be competing with other important tasks for run time? > > > > What you mean important? Until OOM victim task exit completely, the system have no memory. > > all of important task can't do anything. > > > > In almost kernel subsystems, automatically priority boost is really bad idea because > > it may break RT task's deterministic behavior. but OOM is one of exception. The deterministic > > was alread broken by memory starvation. > > Yes or No. > > IMHO, normally RT tasks shouldn't use dynamic allocation(ie, > non-deterministic functions or system calls) in place which is needed > deterministic. So memory starvation might not break real-time > deterministic. I think It's impossible. Normally RT task use mlock and it prevent almost page allocation. but every syscall internally call kmalloc(). They can't avoid it practically. How do you perfectly avoid dynamic allocation? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: KOSAKI Motohiro on 28 May 2010 02:00 > RT Task > > void non-RT-function() > { > system call(); > buffer = malloc(); > memset(buffer); > } > /* > * We make sure this function must be executed in some millisecond > */ > void RT-function() > { > some calculation(); <- This doesn't have no dynamic characteristic > } > int main() > { > non-RT-function(); > /* This function make sure RT-function cannot preempt by others */ > set_RT_max_high_priority(); > RT-function A(); > set_normal_priority(); > non-RT-function(); > } > > We don't want realtime in whole function of the task. What we want is > just RT-function A. > Of course, current Linux cannot make perfectly sure RT-functionA can > not preempt by others. > That's because some interrupt or exception happen. But RT-function A > doesn't related to any dynamic characteristic. What can justify to > preempt RT-function A by other processes? As far as my observation, RT-function always have some syscall. because pure calculation doesn't need deterministic guarantee. But _if_ you are really using such priority design. I'm ok maximum NonRT priority instead maximum RT priority too. Luis, NonRT high priority break your use case? and if yes, can you please explain the reason? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Minchan Kim on 28 May 2010 02:00 On Fri, May 28, 2010 at 2:39 PM, KOSAKI Motohiro <kosaki.motohiro(a)jp.fujitsu.com> wrote: > Hi > >> Hi, Kosaki. >> >> On Fri, May 28, 2010 at 1:46 PM, KOSAKI Motohiro >> <kosaki.motohiro(a)jp.fujitsu.com> wrote: >> >> * Luis Claudio R. Goncalves <lclaudio(a)uudg.org> [2010-05-28 00:51:47]: >> >> >> >> > @@ -382,6 +382,8 @@ static void dump_header(struct task_struct *p, gfp_t gfp_mask, int order, >> >> > */ >> >> > static void __oom_kill_task(struct task_struct *p, int verbose) >> >> > { >> >> > + struct sched_param param; >> >> > + >> >> > if (is_global_init(p)) { >> >> > WARN_ON(1); >> >> > printk(KERN_WARNING "tried to kill init!\n"); >> >> > @@ -413,8 +415,9 @@ static void __oom_kill_task(struct task_struct *p, int verbose) >> >> > */ >> >> > p->rt.time_slice = HZ; >> >> > set_tsk_thread_flag(p, TIF_MEMDIE); >> >> > - >> >> > force_sig(SIGKILL, p); >> >> > + param.sched_priority = MAX_RT_PRIO-1; >> >> > + sched_setscheduler_nocheck(p, SCHED_FIFO, ¶m); >> >> > } >> >> > >> >> >> >> I would like to understand the visible benefits of this patch. Have >> >> you seen an OOM kill tasked really get bogged down. Should this task >> >> really be competing with other important tasks for run time? >> > >> > What you mean important? Until OOM victim task exit completely, the system have no memory. >> > all of important task can't do anything. >> > >> > In almost kernel subsystems, automatically priority boost is really bad idea because >> > it may break RT task's deterministic behavior. but OOM is one of exception. The deterministic >> > was alread broken by memory starvation. >> >> Yes or No. >> >> IMHO, normally RT tasks shouldn't use dynamic allocation(ie, >> non-deterministic functions or system calls) in place which is needed >> deterministic. So memory starvation might not break real-time >> deterministic. > > I think It's impossible. Normally RT task use mlock and it prevent almost page > allocation. but every syscall internally call kmalloc(). They can't avoid > it practically. > > How do you perfectly avoid dynamic allocation? RT Task void non-RT-function() { system call(); buffer = malloc(); memset(buffer); } /* * We make sure this function must be executed in some millisecond */ void RT-function() { some calculation(); <- This doesn't have no dynamic characteristic } int main() { non-RT-function(); /* This function make sure RT-function cannot preempt by others */ set_RT_max_high_priority(); RT-function A(); set_normal_priority(); non-RT-function(); } We don't want realtime in whole function of the task. What we want is just RT-function A. Of course, current Linux cannot make perfectly sure RT-functionA can not preempt by others. That's because some interrupt or exception happen. But RT-function A doesn't related to any dynamic characteristic. What can justify to preempt RT-function A by other processes? -- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Balbir Singh on 28 May 2010 02:30
* KOSAKI Motohiro <kosaki.motohiro(a)jp.fujitsu.com> [2010-05-28 13:46:53]: > > * Luis Claudio R. Goncalves <lclaudio(a)uudg.org> [2010-05-28 00:51:47]: > > > > > @@ -382,6 +382,8 @@ static void dump_header(struct task_struct *p, gfp_t gfp_mask, int order, > > > */ > > > static void __oom_kill_task(struct task_struct *p, int verbose) > > > { > > > + struct sched_param param; > > > + > > > if (is_global_init(p)) { > > > WARN_ON(1); > > > printk(KERN_WARNING "tried to kill init!\n"); > > > @@ -413,8 +415,9 @@ static void __oom_kill_task(struct task_struct *p, int verbose) > > > */ > > > p->rt.time_slice = HZ; > > > set_tsk_thread_flag(p, TIF_MEMDIE); > > > - > > > force_sig(SIGKILL, p); > > > + param.sched_priority = MAX_RT_PRIO-1; > > > + sched_setscheduler_nocheck(p, SCHED_FIFO, ¶m); > > > } > > > > > > > I would like to understand the visible benefits of this patch. Have > > you seen an OOM kill tasked really get bogged down. Should this task > > really be competing with other important tasks for run time? > > What you mean important? Until OOM victim task exit completely, the system have no memory. > all of important task can't do anything. > > In almost kernel subsystems, automatically priority boost is really bad idea because > it may break RT task's deterministic behavior. but OOM is one of exception. The deterministic > was alread broken by memory starvation. > I am still not convinced, specially if we are running under mem cgroup. Even setting SCHED_FIFO does not help, you could have other things like cpusets that might restrict the CPUs you can run on, or any other policy and we could end up contending anyway with other SCHED_FIFO tasks. > That's the reason I acked it. If we could show faster recovery from OOM or anything else, I would be more convinced. -- Three Cheers, Balbir -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |