Re: [RFC] oom-kill: give the dying task a higher priority

From: Minchan Kim
Date: Fri May 28 2010 - 01:51:08 EST


On Fri, May 28, 2010 at 2:39 PM, KOSAKI Motohiro
<kosaki.motohiro@xxxxxxxxxxxxxx> wrote:
> Hi
>
>> Hi, Kosaki.
>>
>> On Fri, May 28, 2010 at 1:46 PM, KOSAKI Motohiro
>> <kosaki.motohiro@xxxxxxxxxxxxxx> wrote:
>> >> * Luis Claudio R. Goncalves <lclaudio@xxxxxxxx> [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, &param);
>> >> > Â}
>> >> >
>> >>
>> >> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/