Path: utzoo!attcan!uunet!zaphod.mps.ohio-state.edu!lavaca.uh.edu!menudo.uh.edu!nuchat!kevin
From: kevin@nuchat.sccsi.com (Kevin Brown)
Newsgroups: comp.os.minix
Subject: Re: Most requested features in MINIX...
Message-ID: <1991Feb6.082308.13552@nuchat.sccsi.com>
Date: 6 Feb 91 08:23:08 GMT
References: <43516@nigel.ee.udel.edu> <8930@star.cs.vu.nl> <743@krabat.marco.de>
Organization: /users/kevin/.organizati/files/news/comp/os/minix
Lines: 73

BTW, to remain on topic, I think we need #! recognition in the kernel.  This
seems to be one big difference between Minix and other flavors of Unix (don't
know if V7 had it or not, though).

In article <743@krabat.marco.de> leo@krabat.marco.de (Matthias Pfaller) writes:
>In article <8930@star.cs.vu.nl>, ast@cs.vu.nl (Andy Tanenbaum) writes:
>> >16. Better scheduling algorithms.
>> It is a single user machine.  Round robin should be good enough for that.

If it were a single-tasking machine, I would agree.  ;-)

>You should know that this simply is not true;
>On page 80 of "Operating systems: Design and Implementation" you mention some
>criteria what a good scheduler should try to achive. For a single user
>machine I think that at least point 1 and 3 are interesting.
>1. Fairness: make sure each process gets its fair shar of the CPU
>	This is NOT true for the current scheduling algorithm of minix.
>	Compute-bound processes have a higher preference then IO-bound
>	processes. This is because if a IO-bound process gives up the CPU
>	to make a call to the fs. Now the CPU-bound process consumes his
>	timeslice complete, even if the systemcall of the IO-bound process
>	has allready finished; So the CPU-bound process gets 99% of the
>	CPU-Time.
>
>This makes point 3 impossible:
>3. Response time: minimize response time for interactive users.

Yup.  The question is at what cost (in terms of simplicity) do you get a
better scheduling algorithm?  If the changes are only a few lines, then
I agree that they should be made part of the standard distribution.  Let's
face it: Minix isn't just about teaching OS, it's also about teaching GOOD
OS techniques.  I think a good scheduler is part of that, and thus think
it should be part of the Minix distribution (IF it's simple, of course :-).

>One of the features of minix is Multitasking/programing; So if I compile
>in the background, I wish to have a acceptable responsetime in the foreground.
>I have read all the articles about multithreading fs... and I thought:
>Ok, the bad response time is because all these fs-calls can't be done in
>parallel. But then I build Kai-Uwe's priority-driven scheduler into my
>minix 1.5-kernel. From this point of time I never even wasted ONE thought for
>a multi-threading fs; The responsetime is now acceptable; I can compile
>in the Background and let an editor running in the foreground; I almost allways
>get immediate response to key-presses.

Please, Please, PLEASE, PUHLEEEZE post the diffs relative to vintage 1.5.10
for this!  I know I would find it useful, and I suspect MANY others would
find it useful as well.  I eventually want to get UUCP, mail, and news up
on my machine, and something like this will make a big difference.

Unless I'm being brain dead here.  Is the scheduler you refer to something
that has actually been posted here already?  If so, could you email it to
me (or, better yet, do the context diffs anyway, unless you made no changes
to anything when you did the installation, i.e. no bug fixes and the like).

>I think a better scheduling algorithm would be a real winn for minix and
>1. It's a real small change to the kernel (only a few lines)

It is?  Cool.  I'm looking forward to this.  :-)

>2. You would hear the 'why is fs not multi-threaded ...' much less

How well does the scheduling algorithm deal with multiple I/O-bound
processes going on at the same time, e.g. two compiles?  How well does
it deal with multiple users?

>	Matthias Pfaller (leo @ marco.de)


--
Kevin Brown						Disclaimer: huh?
nuchat!kevin@uunet.uu.net		or		csci31f7@cl.uh.edu 

Minix -- the Unix[tm] of the 90's.  System V -- the Multics of the 90's.  :-)


Brought to you by Super Global Mega Corp .com