Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!elroy.jpl.nasa.gov!usc!wuarchive!udel!mmdf
From: I5110401%DBSTU1.BITNET@cunyvm.cuny.edu (Hello world !!)
Newsgroups: comp.os.minix
Subject: Re: Most requested features in MINIX...
Message-ID: <44623@nigel.ee.udel.edu>
Date: 14 Feb 91 13:21:53 GMT
Sender: mmdf@ee.udel.edu
Lines: 44

nicolas@cli52or.edf.fr wrote:
>>(good explanation of cpu-bound vs. io-bound procs with the minix scheduler)
>> This makes point 3 impossible:
>> 3. Response time: minimize response time for interactive users.
>>
>> 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.
>>
>
>Perhaps could you post your diffs, and you will get some reactions ...
>I think it could be interesting for some of us

I *know* i've annonunced this some time ago, but then... 9-)

I am actually preparing my sysupd2 upgrade kit, which basically contains an
implementation of nice(1,2), profil(2), monitor(3) and a port of the bsd
gprof(1). At the moment i am awaiting comments from some "beta testers".
Anyway, i think everything is ready next week, so expect a posting at the
end of that week. The main point is i don't have a person for a pc port of
profil(2). This one is processor dependent in some way, and i can't test
my code. Volunteers appreciated 9-).

Unfortunately it's a diff kit for my sysupd1 kit i've posted a quite long
time ago. However, i've warned you about this when posting sysupd1.tar.Z.
If enough persons yell at me i will maybe be convinced and port everything
back to native 1.5.10 (but that will last another time slice).

To say something about the new scheduling algorithm:
Every user process now has a base priority and a current priority, the latter
one being recalculated after every descheduling operation for the process. The
new current priority is a linear combination of the base priority and the
time the process has used up in its last two scheduling quantums. This way
I/O-intensive processes get lower priority then a cpu-bound process with the
same base priority, hence the response time for the "editing while compiling
in background"-example are significantly better for the editor. See the above
comments from Matthias.