Path: utzoo!attcan!uunet!husc6!rutgers!mcnc!spl From: spl@mcnc.org (Steve Lamont) Newsgroups: comp.unix.wizards Subject: Re: What kinds of things would you want in the GNU OS? Message-ID: <4616@alvin.mcnc.org> Date: 1 Jun 89 21:49:03 GMT References: <106326@sun.Eng.Sun.COM> <422@ladcgw.ladc.bull.com> <13688@ncoast.ORG> <4609@alvin.mcnc.org> <424@ladcgw.ladc.bull.com> Reply-To: spl@mcnc.org.UUCP (Steve Lamont) Organization: Microelectronics Center of NC; RTP, NC Lines: 88 In article <424@ladcgw.ladc.bull.com> frank@ladc.bull.com (Frank Mayhar) writes: >In article <4609@alvin.mcnc.org> spl@mcnc.org.UUCP (Steve Lamont) writes: >>As quoted from <422@ladcgw.ladc.bull.com> by frank@ladc.bull.com (Frank Mayhar): >>| course). If you're writing a Real Operating System, why worry about machines >>| that won't support virtual memory. Hell, by the time Gnu is ready, non-VM >>| machines will probably be a thing of the past anyway. Shared libraries >>Like the Cray Y-MP or Cray 3? [...] > [deletion] >Actually, IMHO, a Cray is a very poor choice of hardware to run a general- >purpose OS on. As I see it, you would want the Cray to run a minimal kernel Why? Just because it is very fast? Sounds good to me! You don't give any arguments to support your contention, so that gives me the privilege of setting up a straw-person argument for the express purpose of knocking it over (I love arguing with myself... I usually get to win! :-) ). A common criticism heard (and one that I made until I began working on interactive Crays some three years ago) is that you don't want to be running vi or emacs on a Cray. The character level interrupts will kill the poor thing. This is simply not true. They simply do not happen frequently enough (from the machine's perspective) to worry about. If scheduling is done correctly (that is, you schedule memory instead of cpus) then the editor tasks are frequently tucked away in some unused crack in memory that would be idle anyhow. If priorities are adjusted correctly, then the task will stay in memory for quite a while before it gets bumped out. Meanwhile, your favorite bomb code is happily simulating the end of the universe unperturbed. >(primarily consisting of a scheduler) that accepts compute-bound jobs from >a client machine running some general OS, and executes them. Basically, >a high-speed backend that runs those cpu bound jobs that are so hard on >general-purpose OS's, and that's *all* it does. The general-purpose OS >(running on a virtual memory machine :-) performs task scheduling, memory >allocation, job queueing, etc, and hands the jobs to the Cray. This is a batch processor model which will work in a number of cases, for FORTRAN finite element weenies simulating the melt down of the local nuke plant, or any other long running job, f'rinstance. However, there are also a number of situations where the user wishes to interact with the computation. In a batch mode, you really can't do that. I suppose that a really smart compiler and operating system could divide up the task into interactive and computationally intensive subtasks, running the compute-bound task on the supercomputer but that's a non-trivial thing to do and, to my knowledge, a continuing topic of research. Perhaps you could migrate tasks from one CPU to another as their resource utilization profile changed. I don't know. All I do know is that there are a number of fairly successful interactive tools in common usage on Crays and TCP/IP coupled Cray and workstation systems. Interactivity is a must! Consider, if you will, the task of debugging. In a batch mode, the cycle is: Submit job Wait for results Edit source file to add PRINTs or fprintf()s. Resubmit Wait Edit... Etc, etc, etc. I know, because that's how I debugged on a batch Cray before I began working on an interactive Cray. A tool such as adb or dbx or whatever your favorite debugger might be tightens the cycle considerably on a supercomputer in just the same manner as it does on a workstation or a minicomputer. >Disclaimer: I have no direct knowledge of how Crays work. When I made my >comment, it was in reference to general-purpose operating systems. And, no, >I don't think that a Cray has any business running a Real Operating System. >(Half :-) Since you half smiley that one, I'll give you a half serious rebuttal :-). A Cray, or, again, any other supercomputer, should not be thought of as simply a compute server. It is, indeed, a general purpose system which, when the operating system is properly tuned, provides considerable interactivity. Crays are Real (actually Double Precision) computers which need Real Operating Systems (do I have to include the silly LUSENET (TM) here? :-) ) If you still have doubts about this, I think I know where I can find you a Model 029 card punch, if your really need one for your next Cray run. ( Full :-) with oak leaf clusters ). -- spl Steve Lamont, sciViGuy EMail: spl@ncsc.org North Carolina Supercomputing Center Phone: (919) 248-1120 Box 12732/RTP, NC 27709