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: balbir@linux.vnet.ibm.com,
	"Luis Claudio R. Goncalves" <lclaudio@uudg.org>,
	Oleg Nesterov <oleg@redhat.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Peter Zijlstra <peterz@infradead.org>,
	David Rientjes <rientjes@google.com>, Mel Gorman <mel@csn.ul.ie>,
	williams@redhat.com
Subject: Re: [RFC] oom-kill: give the dying task a higher priority
Date: Fri, 28 May 2010 16:52:23 +0900	[thread overview]
Message-ID: <AANLkTinLN0ex0uvwA_tohv7MSLHv8i8Mcr96va1C4Md-@mail.gmail.com> (raw)
In-Reply-To: <20100528145329.7E2D.A69D9226@jp.fujitsu.com>

On Fri, May 28, 2010 at 2:59 PM, KOSAKI Motohiro
<kosaki.motohiro@jp.fujitsu.com> wrote:
>> 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.

Hmm. It's just example. but it would be not good exmaple.
Let's change it with this.

void RT-function()
{
     int result = some calculation(); <- This doesn't have no dynamic
characteristic
     *mmap_base = result; <-- mmap_base is mapped by GPIO device.
}

Could we allow preemption of this RT function due to other task's
memory pressure?
Of course, Linux is not Hard RT featured OS, I think. So I thinks it
is a policy problem.
If we think system memory pressure is more important than RT task and
we _all_ agree such policy, we can allow it.

But I don't hope it.

-- 
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-05-28  7:52 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-27 18:04 Luis Claudio R. Goncalves
2010-05-27 18:33 ` Oleg Nesterov
2010-05-28  2:54   ` KOSAKI Motohiro
2010-05-28  3:51     ` Luis Claudio R. Goncalves
2010-05-28  4:33       ` Balbir Singh
2010-05-28  4:46         ` KOSAKI Motohiro
2010-05-28  5:30           ` Minchan Kim
2010-05-28  5:39             ` KOSAKI Motohiro
2010-05-28  5:50               ` Minchan Kim
2010-05-28  5:59                 ` KOSAKI Motohiro
2010-05-28  7:52                   ` Minchan Kim [this message]
2010-05-28 12:53                   ` Luis Claudio R. Goncalves
2010-05-28 14:06                     ` Minchan Kim
2010-05-28 14:20                       ` Balbir Singh
2010-05-28 15:03                         ` Minchan Kim
2010-05-28 14:36                       ` Luis Claudio R. Goncalves
2010-05-28 15:12                         ` Minchan Kim
2010-05-28 15:21                           ` Peter Zijlstra
2010-05-28 15:35                             ` Minchan Kim
2010-05-28 15:28                           ` Luis Claudio R. Goncalves
2010-05-28 15:45                             ` Minchan Kim
2010-05-28 16:48                               ` Luis Claudio R. Goncalves
2010-05-29  3:59                                 ` KOSAKI Motohiro
2010-05-31  2:15                                   ` Luis Claudio R. Goncalves
2010-05-31  5:06                                   ` Minchan Kim
2010-05-31  6:35                                     ` KOSAKI Motohiro
2010-05-31  7:05                                       ` Minchan Kim
2010-05-31  7:25                                         ` KAMEZAWA Hiroyuki
2010-05-31  9:30                                           ` Minchan Kim
2010-05-30 15:09                                 ` Minchan Kim
2010-05-31  0:21                                 ` KAMEZAWA Hiroyuki
2010-05-31  5:01                                   ` Minchan Kim
2010-05-31  5:04                                     ` KAMEZAWA Hiroyuki
2010-05-31  5:46                                       ` Minchan Kim
2010-05-31  5:54                                         ` KAMEZAWA Hiroyuki
2010-05-31  6:09                                           ` Minchan Kim
2010-05-31  6:51                                             ` KAMEZAWA Hiroyuki
2010-05-31 10:33                                               ` Minchan Kim
2010-05-31 13:52                                               ` Luis Claudio R. Goncalves
2010-05-31 23:50                                                 ` KAMEZAWA Hiroyuki
2010-06-01 17:35                                                   ` Luis Claudio R. Goncalves
2010-06-01 20:49                                                     ` David Rientjes
2010-06-02 13:54                                                       ` KOSAKI Motohiro
2010-06-02 14:20                                                         ` Luis Claudio R. Goncalves
2010-06-02 21:11                                                         ` David Rientjes
2010-06-02 23:36                                                           ` KOSAKI Motohiro
2010-06-03  0:52                                                             ` Minchan Kim
2010-06-03  7:50                                                           ` Peter Zijlstra
2010-06-03 20:32                                                             ` David Rientjes
2010-06-01  8:19                                                 ` Minchan Kim
2010-06-01 18:36                                                   ` David Rientjes
2010-05-28  6:27           ` Balbir Singh
2010-05-28  6:34             ` KAMEZAWA Hiroyuki
2010-05-28  6:38             ` KOSAKI Motohiro
2010-05-28 15:53       ` Peter Zijlstra

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=AANLkTinLN0ex0uvwA_tohv7MSLHv8i8Mcr96va1C4Md-@mail.gmail.com \
    --to=minchan.kim@gmail.com \
    --cc=balbir@linux.vnet.ibm.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=lclaudio@uudg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mel@csn.ul.ie \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rientjes@google.com \
    --cc=tglx@linutronix.de \
    --cc=williams@redhat.com \
    /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