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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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, 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/ .
Don't email: <a href


[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]