Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!bpa!cbmvax!vu-vlsi!mpx1!mpx2!erik
From: erik@mpx2.mpx.com (Erik Murrey)
Newsgroups: comp.unix.wizards
Subject: Re: What kinds of things would you want in the GNU OS?
Keywords: GNU OS features kernel fun!
Message-ID: <3@mpx2.mpx.com>
Date: 30 May 89 15:53:10 GMT
References: <106326@sun.Eng.Sun.COM> <422@ladcgw.ladc.bull.com> <28855@cci632.UUCP>
Reply-To: erik@mpx2.UUCP (Erik Murrey)
Organization: MPX Data Systems, Inc. ,  Wayne, PA
Lines: 43

In article <28855@cci632.UUCP> tvf@ccird7.UUCP (Tom Frauenhofer) writes:
>In article <422@ladcgw.ladc.bull.com> frank@ladc.bull.com (Frank Mayhar) writes:
>>How about scheduling processes on a per-login basis, rather than
>>per-process.  I.e. a user has a certain quantum that is divided
>>between all the processes he starts.  (It should be configurable,
>>and maybe even adjustable on the fly by a privileged user.)  This
>>would keep one user from starting sixteen compiles and bringing a
>>system to its knees.
>
>Fair to users, maybe.  How would you handle daemons?  Is each daemon its
>own process group?  Or can they be grouped together somehow?

How about having separate scheduler queues ala OS/2 (ugh!).  Make a
queue for daemons, a queue for interactive processes, and a queue for
real-time processes.  Each processes within that queue can also elect
(or be assigned) a priority within that queue, similar to a nice
value.

The theory is that real-time queue gets acted upon immediately
following a condition that was blocking it.  Processes within that
queue are very immune to time-slice restrictions, except for other
processes within that queue.  (Watch out for tight loops...)

The interactive process queue will be acted upon immediately following
any condition that was blocking it, such as terminal I/O, disk I/O,
etc.  This provides the response necessary for user interfaces, and
medium speed communications programs.

The daemon process queue will only run when all other processes are
blocked on I/O, or when the processes has been blocked by an
interactive process for some absurd amount of time.

Of course, all of the above would need fine-tuning, and more rules....

... Erik



-- 
Erik Murrey                            /|   //  /~~~~/  |  /
MPX Data Systems, Inc.                / | / /  /____/   |/
erik@mpx.com                         /  /  /  /        /|  Data Systems, Inc. 
{vu-vlsi, bpa, cbmvax}!mpx1!erik    /     /  /       /  |====================