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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTikB-8Qu03VrA5Z0LMXM_alSV7SLqzl-MmiLmFGv@mail.gmail.com>
Date:	Fri, 28 May 2010 14:50:55 +0900
From:	Minchan Kim <minchan.kim@...il.com>
To:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
Cc:	balbir@...ux.vnet.ibm.com,
	"Luis Claudio R. Goncalves" <lclaudio@...g.org>,
	Oleg Nesterov <oleg@...hat.com>, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org, Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>,
	David Rientjes <rientjes@...gle.com>,
	Mel Gorman <mel@....ul.ie>, williams@...hat.com
Subject: Re: [RFC] oom-kill: give the dying task a higher priority

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