From: Momchil Velikov <velco@fadata.bg>
To: george anzinger <george@mvista.com>
Cc: Davide Libenzi <davidel@xmailserver.org>,
lkml <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] Scheduler issue 1, RT tasks ...
Date: 21 Dec 2001 00:21:37 +0200 [thread overview]
Message-ID: <87y9jxzg5q.fsf@fadata.bg> (raw)
In-Reply-To: <Pine.LNX.4.40.0112201252450.1622-100000@blue1.dev.mcafeelabs.com> <3C22654D.7FC80713@mvista.com>
In-Reply-To: <3C22654D.7FC80713@mvista.com>
>>>>> "George" == george anzinger <george@mvista.com> 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.
Regards,
-velco
next prev parent reply other threads:[~2001-12-20 22:37 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-20 21:11 [RFC] Scheduler issue 1, RT tasks Davide Libenzi
2001-12-20 22:25 ` george anzinger
2001-12-20 22:21 ` Momchil Velikov [this message]
2001-12-20 22:57 ` Davide Libenzi
2001-12-21 17:00 ` Mike Kravetz
2001-12-21 17:19 ` Davide Libenzi
2001-12-21 17:33 ` Mike Kravetz
2001-12-21 18:29 ` Davide Libenzi
2001-12-24 0:18 ` Victor Yodaiken
2001-12-24 1:31 ` Davide Libenzi
2001-12-24 5:33 ` Victor Yodaiken
2001-12-24 18:52 ` Davide Libenzi
2001-12-27 3:01 ` Victor Yodaiken
2001-12-27 17:41 ` Davide Libenzi
2001-12-28 0:05 ` Victor Yodaiken
2001-12-28 0:48 ` Davide Libenzi
2001-12-20 22:36 ` Davide Libenzi
2001-12-24 0:19 ` Victor Yodaiken
2001-12-24 1:20 ` Davide Libenzi
2001-12-27 3:42 ` Victor Yodaiken
2001-12-27 17:48 ` Davide Libenzi
-- strict thread matches above, loose matches on Subject: below --
2001-12-28 9:45 Martin Knoblauch
2001-12-29 9:12 ` george anzinger
2001-12-29 19:02 Dieter Nützel
2001-12-29 21:00 ` Andrew Morton
2001-12-29 22:24 ` Davide Libenzi
[not found] <200112291907.LAA25639@messenger.mvista.com>
2001-12-30 10:01 ` george anzinger
2001-12-30 19:54 ` Dieter Nützel
2001-12-31 13:56 ` george anzinger
2002-01-01 18:55 ` Dieter Nützel
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=87y9jxzg5q.fsf@fadata.bg \
--to=velco@fadata.bg \
--cc=davidel@xmailserver.org \
--cc=george@mvista.com \
--cc=linux-kernel@vger.kernel.org \
/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