Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!bellcore!ulysses!burl!codas!akgua!usl!elg From: elg@usl.UUCP (Eric Lee Green) Newsgroups: net.arch Subject: Re: paging and loading Message-ID: <949@usl.UUCP> Date: Sat, 27-Sep-86 02:24:10 EDT Article-I.D.: usl.949 Posted: Sat Sep 27 02:24:10 1986 Date-Received: Thu, 9-Oct-86 01:47:24 EDT References: <832@hou2b.UUCP> <7597@lanl.ARPA> <78@alberta.UUCP> Reply-To: elg@usl.UUCP (Eric Lee Green) Organization: USL, Lafayette, La. Lines: 78 Summary: A paging cray almost as fast as a non-paging cray In article <78@alberta.UUCP> cdshaw@pembina.UUCP (Chris Shaw) writes: >People who are saying "the 205 runs programs x, y, and z faster without VM than >with VM" are looking at only one job at a time. This is fine if your 205 does >ONLY 1 thing all day, every day. Anyone who was around in the days of >"batch only" knows this argument inside and out. Batch is fine if you want >to maximize individual program performance, but overall turnaround time is >dreadful, since ALL things sit in the queue, including the 1/2 second >practice runs. >Chris Shaw cdshaw@alberta A rehash of past arguments, about the working through huge matrix problem: "By the time we reach the end of the list, the front of the list will have been paged out". If the front of the matrix has been paged out, that means that the matrix was too big to fit in physical memory. That means that with no paging, the performance would be 0 -- a 100% degradation. "We can take advantage of disk seek times -- just put the data on close tracks." All the disk systems I have ever seen become somewhat fragmented over time. Also note that, because of intelligent i/o controllers, pulling a page off of disk takes virtually no CPU time, since the processor is running another process while the first one is blocked waiting for the i/o processor to bring in the page (assuming a multi-tasking system -- Crays and such DO multi-task, no?). In otherwords taking advantage of explicit multi-processing. Most of the other arguments seen have been spurious line noise :-) :-). The only one which is really valid is the table lookup times necessary for paging. Worst case: the large matrix previously discussed. For n=page size, every n bytes we have to fetch a new associative table entry, upon which one-two levels of a tree must be traversed. There is also the overhead of paging in the MMU lookup table the initial time. With today's faster disk drives, larger pages may help, both in increasing the time N between memory-to-associative fetches, and in decreasing the size of the MMU lookup table. If 4k was OK back in Multics days, 8K or even 16K might work today. Also note that this is WORST CASE. Your mileage will probably be better. I must conclude that for 4k word pages, every 4k memory operations, a 2-4 cycle overhead would be necessary. or, a 4/4096 reduction in performance. If we are talking about a 100 MIPS machine, it would now only be running at 99.92 MIPS. Like wow. Especially considering that because associative lookups probably run about the same speed as checking bounds registers, the memory speed would be otherwise about the same. Another argument was that paging messes up pipelining. Correct me if I'm wrong (we obviously don't have a Cray handy :-), but a Cray only does pipelined vector operations upon the vector registers (although I think filling and saving those registers are pipelined operations, also). Requiring vectors to be page-aligned and having the pages the same size as the registers or a binary size larger would eliminate any pipeline lossage (just do your virtual memory grocking BEFORE you get your pipeline rolling). Since the compilers already have to do considerable grocking to vectorize code, that doesn't seem too extreme. And, of course, MIPS machines & others prove that for ordinary code, pipelining and paging are not mutually exclusive. Of course, the OTHER Big Win of paging is when you want to run a Truly Humongous working set of programs.. But I think others have already covered this, plus there's always the argument "Hey, I've got offset registers and 2 gigabytes of RAM, what more could I want!". Upon which someone will discover a problem that takes 2,147,483,650 bytes to solve... In summary, I really can't see any reason to not have paging, and since there's a multitude of reasons to HAVE paging (running problem sets larger than available memory, "graceful" user response time as vs. multitasking schemes such as segmentation or swapping, etc.)... -- Eric Green {akgua,ut-sally}!usl!elg (Snail Mail P.O. Box 92191, Lafayette, LA 70509) " In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move."