What kinds of things would you want in the GNU OS?

[Frank Mayhar]

In article <28855 at cci632.UUCP> tvf at ccird7.UUCP (Tom Frauenhofer) writes:
>In article <422 at ladcgw.ladc.bull.com> I write:
>>In article <106326 at sun.Eng.Sun.COM> bitbug (James Buster) writes:
>>}What kinds of things should be in the GNU Kernel?
>>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?

Well, they're all started at boot time (for the most part); group them
together by forcing them to inherit the scheduling parameters of their
parent (which is init, in this case: _the_ most privileged user).  Or
make the parent adjust the scheduling parameters on the fly for each
daemon, to each according to its needs.  Fortunately, most daemons don't
require a lot of time; most of the time they are sleeping waiting for
something to happen.  Of course, when they do need time, they need it bad,
and they may need a lot of it.  So make them privileged, so that they
can change their own parameters.  Or make each one a separate user,
with it's own (configured) quantum value.  Then each of the children
of such processes would share the parent's quanta.  One advantage:
sendmail wouldn't bring the system to its knees when it's very active.
My most important point is that this stuff should be configurable, both
by the system manager in some static location, and dynamically, at run
time, for each user, and, perhaps, for each process.

>Even if you do this, the processes will still get in the way of each other
>due to paging requirements.  You would have to go to a local paging/working
>set system to cut out this interaction.  This is a gain if one of your goals
>is real-time, but it requires a more intelligent user who can determine an
>optimum working set size.

Since memory is (and will probably always be) a limited resource, I don't
see any way to completely cure this.  But you could prefer paging out the
pages of another process for the same user, over paging out the pages of
a process not associated with the current user.  If the current user (who
needs the page[s]) only has one process, then go looking for pages from
other processes.

>Another way processes interfere with each other is the kernel call mechanism
>that UNIX uses where (I recall, mucho simplified) when one process is making
>a kernel call others cannot (unless, of course, the process in the kernel is
>blocked for some reason, say on a semaphore or because it is waiting on an
>I/O call to be serviced).

Sounds broken to me; fix it.  The way we get around this is by having per-user
auto stack, control blocks, etc.  When the user's quantum ends, he is put
to sleep, and we switch contexts.  Obviously, there are some things that
can't be interrupted, so we have a mechanism to extend the quantum.  (Or
we just automatically extend the quantum; I'm not sure, since the scheduler
is not part of the code I'm responsible for.  I have the file management
system.)  Basically, at the end of the quantum, we block the user.  Since
our monitor is fully reentrant (with a very few exceptions), another user
can issue a monitor call with no problems.

>All of the above have been done in various OS's.  It all boils down to the
>goals of the GNU team (which is point I don't know much about).  Do they
>want to emulate UNIX?  Or do they want to come up with something different?
>It would be nice to see their design goals spelled out.

Quite true.  It would be nice to see something that used some of the good
parts of Unix, and at the same time fixed most of the broken parts.  (I
know, I better go put on my flame-proof suit, now. :-)

>Mind you, none of this will affect the GNU kernel design one whit...

Also true.  But I keep hoping...
-- 
Frank Mayhar  ..!uunet!ladcgw!frank (frank at ladc.bull.com)
              Bull HN Los Angeles Development Center
              5250 W. Century Blvd., LA, CA  90045  Phone:  (213) 216-6241