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

[Minchan Kim]

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