public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: george anzinger <george@mvista.com>
To: Davide Libenzi <davidel@xmailserver.org>
Cc: lkml <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] Scheduler issue 1, RT tasks ...
Date: Thu, 20 Dec 2001 14:25:17 -0800	[thread overview]
Message-ID: <3C22654D.7FC80713@mvista.com> (raw)
In-Reply-To: <Pine.LNX.4.40.0112201252450.1622-100000@blue1.dev.mcafeelabs.com>

Davide Libenzi wrote:
> 
> I'd like to have some comments about RT tasks implementation in a SMP
> system because POSIX it's not clear about how the priority rules apply to
> multiprocessor systems.
> The Balanced Multi Queue Scheduler ( BMQS, http://www.xmailserver.org/linux-patches/mss-2.html )
> i'm working on tries to keep CPU schedulers the more independent as
> possible and currently implements two kind of RT tasks, local one and
> global ones.
> 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. This keeps schedulers interlocking very low
> because of the very fast path in reschedule_idle() ( no multi lock
> acquisition, CPU queue loops, etc...).
> Global RT tasks, that live in a separate run queue, have the ability to
> preempt remote CPU and this can lead ( in the unfortunate case that the
> last CPU running the RT task is running another RT task ) to an higher
> cost in reschedule_idle().
> The check for a global RT task selection is done in a very fast way before
> checking the local queue :
> 
>     if (!list_empty(&runqueue_head(RT_QID)))
>         goto rt_queue_select;
> rt_queue_select_back:
> 
> and this does not affect the scheduler latency at all.
> On the contrary, by having a separate queue for global RT tasks, can
> improve it in high run queue load cases.
> 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.
> I'd like to have comments on this before jumping to the next Scheduler
> issue ( balancing mode ).
> 
My understanding of the POSIX standard is the the highest priority
task(s) are to get the cpu(s) using the standard calls.  If you want to
deviate from this I think the standard allows extensions, but they IMHO
should be requested, not the default, so I would turn your flag around
to force LOCAL, not GLOBAL.

-- 
George           george@mvista.com
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Real time sched: http://sourceforge.net/projects/rtsched/

  reply	other threads:[~2001-12-20 22:26 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 [this message]
2001-12-20 22:21   ` Momchil Velikov
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=3C22654D.7FC80713@mvista.com \
    --to=george@mvista.com \
    --cc=davidel@xmailserver.org \
    --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