From owner-freebsd-hackers  Sat Jul 29 06:34:24 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.11/8.6.6) id GAA17778
          for hackers-outgoing; Sat, 29 Jul 1995 06:34:24 -0700
Received: from fathergoose.net6c.io.org (fathergoose.net6c.io.org [204.92.6.86])
          by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id GAA17772
          for <hackers@freebsd.org>; Sat, 29 Jul 1995 06:34:19 -0700
Received: (from kwong@localhost) by fathergoose.net6c.io.org (8.6.11/8.6.10) id JAA00264; Sat, 29 Jul 1995 09:24:36 -0400
From: Ken Wong <kwong@fathergoose.net6c.io.org>
Message-Id: <199507291324.JAA00264@fathergoose.net6c.io.org>
Subject: Re: Scheduling Algorithms (was: Re: panic in brelse() ... )
To: terry@cs.weber.edu (Terry Lambert)
Date: Sat, 29 Jul 1995 09:24:35 -0400 (EDT)
Cc: hackers@freebsd.org
In-Reply-To: <9507262109.AA23296@cs.weber.edu> from "Terry Lambert" at Jul 26, 95 03:09:58 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1430      
Sender: hackers-owner@freebsd.org
Precedence: bulk

> 
> [ ... a proposed linear reduction scheduling algorithm ... ]
> 
> [ ... the BSD 4.4 algorithm ... ]
> 
> [ ... the current FreeBSD modified BSD 4,.4 algorithm ... ]
> 
> [ ... the Amiga time base promotion algorithm ... ]
> 
> I think all of these algorithms miss the boat, if we are to be able
> to support RT scheduling and SMP scheduling.
> 
> The main issue in both of these tasks that are on the table is a
> divorce of the ready-to-run state from the act of running the
> code.  I think that this really implies seperate queues based
> on priority.

I think single queue is best serve here. if we want realtime and 
SMP.
I know some RT SMP system does it by dividing priority into 2 sections
	1) RT 0-7 
	2) the Rest is Timeshring
within each group, round robin is used to dispatch proceess with
the same priority. within group 2) some other algo can still be
used to change the priority but never goes up to 1). 1) is fix
priority and pre-emptive. the process table can include cpu which
it will execute.

> 
> It's necessary because multiple processes can be in the run state (for
> SMP, or even for kernel premption), and RT processes have to be able
> to be pigs as much as they want (if they are supported).

the above would solve this problem.

> 
> 
> 					Terry Lambert
> 					terry@cs.weber.edu
> ---
> Any opinions in this posting are my own and not those of my present
> or previous employers.
> 


Ken Wong