Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!ladcgw!frank From: frank@ladc.bull.com (Frank Mayhar) 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: <423@ladcgw.ladc.bull.com> Date: 28 May 89 00:48:46 GMT References: <106326@sun.Eng.Sun.COM> <422@ladcgw.ladc.bull.com> <28855@cci632.UUCP> Reply-To: frank@ladc.bull.com (Frank Mayhar) Organization: Bull HN Los Angeles Development Center Lines: 74 In article <28855@cci632.UUCP> tvf@ccird7.UUCP (Tom Frauenhofer) writes: >In article <422@ladcgw.ladc.bull.com> I write: >>In article <106326@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@ladc.bull.com) Bull HN Los Angeles Development Center 5250 W. Century Blvd., LA, CA 90045 Phone: (213) 216-6241