Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!umcp-cs!chris
From: chris@umcp-cs.UUCP (Chris Torek)
Newsgroups: net.unix-wizards
Subject: Re: 4.2bsd kernel auto-nicing, scheduling
Message-ID: <32@umcp-cs.UUCP>
Date: Mon, 3-Mar-86 04:16:52 EST
Article-I.D.: umcp-cs.32
Posted: Mon Mar  3 04:16:52 1986
Date-Received: Tue, 4-Mar-86 04:11:37 EST
References: <1014@brl-smoke.ARPA> <669@frog.UUCP>
Organization: U of Maryland, Computer Science Dept., College Park, MD
Lines: 34

Well, I guess it is time for me to step into the fray at last.

In article <4516@topaz.RUTGERS.EDU> root@topaz.UUCP (probably Chuck Hedrick)
writes:

>... The default DEC-20 scheduler sounds a lot like what [Jeff et
>al.] have done. ... we found was that under heavy load Emacs ran
>just great, but the first time you tried to compile, you might as
>well go out for dinner....

Funny thing, just a few hours ago I was talking to one of the local
grad student hackers here, and mentioned that I was afraid that we
might start to see the same thing.

>We finally ended up using the "class scheduler".  [It] keeps track
>of what average share of the CPU is going to each user.  It gives
>boosts or penalties depending upon whether you are getting more or
>less than your fair share.
>
>I concluded that what most people really expect to get out of a
>timesharing system is 1/N of the machine, where N is the load
>average.

That was what I said *I* wanted, at any rate.  If the load is 10,
I expect to be able to get ~1/10th of the machine myself.  If I
choose to spend it on compilations, I *still* expect to get `my'
share of the CPU power of the machine.  Of course, if I start
editing at the same time, I would rather my editor get most of my
1/10th, not my compile, which indicates that event-based scheduling
is still a good idea.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1415)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@mimsy.umd.edu