[lkml]   [2001]   [Dec]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] Scheduler issue 1, RT tasks ...
On 21 Dec 2001, Momchil Velikov wrote:

> >>>>> "George" == george anzinger <> writes:
> George> Davide Libenzi wrote:
> >> Local RT tasks apply POSIX priority rules inside the local CPU, that means
> >> that an RT task running on CPU0 cannot preempt another task ( being it
> >> normal or RT ) on CPU1.
> [...]
> >> Global RT tasks, that live in a separate run queue, have the ability to
> >> preempt remote CPU and this can lead.
> [...]
> >> The local/global RT task selection is done with setscheduler() with a new
> >> ( or'ed ) flag SCHED_RTGLOBAL, and this means that the default is RT task
> >> local.
> George> My understanding of the POSIX standard is the the highest priority
> George> task(s) are to get the cpu(s) using the standard calls. If you want to
> George> deviate from this I think the standard allows extensions, but they IMHO
> George> should be requested, not the default, so I would turn your flag around
> George> to force LOCAL, not GLOBAL.
> I'd like to second that, IMHO the RT task scheduling should trade
> throughput for latency, and if someone wants priority inversion, let
> him explicitly request it.

No a great performance loss anyway. It's zero performance loss if the CPU
that has ran the woke up RT task for the last time is not running another
RT task ( very probable ). If the last CPU of the woke up task is running
another RT task a CPU discovery loop ( like the current scheduler ) must
be triggered. Not a great deal anyway.

- Davide

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:14    [W:0.133 / U:0.088 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site