Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!mailrus!tut.cis.ohio-state.edu!bloom-beacon!gatech!hubcap!ncrcae!ece-csc!mcnc!ecsvax!tpmsph From: tpmsph@ecsvax.UUCP (Thomas P. Morris) Newsgroups: comp.arch Subject: Re: VM needed for rapid startup Summary: You can cluster or prepage, too Keywords: paging virtual-memory speed Message-ID: <5149@ecsvax.UUCP> Date: 26 May 88 23:08:49 GMT References: <463@cvaxa.sussex.ac.uk> <19322@beta.UUCP> Organization: UNC Educational Computing Service Lines: 58 In article <19322@beta.UUCP>, jlg@beta.UUCP (Jim Giles) writes: > One of the things that makes virtual memory LESS useful than it used to be > is the fact that disk is so slow compared to main memory (and CPU speed). > If it takes less than the disk access time for your program to execute > through a whole page of code, a busy multiprocessing environment may spend > nearly all its time waiting on page faults. Your operating system doesn't have to actually page in only a single page of code or data at a time, though. Some operating systems use the concept of a `page fault cluster' or the number of pages of code or data which will be fetched from disk as a group upon a single `hard' page fault. (IE a fault which actually causes a read from disk) That way your OS can hide, to a certain extent, some of the cost of having to go to the disk. Yes, that first fault costs you a lot of time. But the time to read in 32 or 64 pages is not much worse than the time to read in just one. I would guess that if your program then only touches even ==one== of those other pre-paged/pre-fetched pages, instead of having to read it from the disk, then you have more than made up for the additional time it took to read 32 or 64 blocks, rather than just one. > ...... implement a paging scheme > off the intermediate storage (which in turn can page off disk in larger > chunks?). Exactly. See above. Your `intermediate storage' could, indeed, be your free-page list. That is, when your OS pre-fetches those pages, it could map only the `fault-causing' page into your working set. Those other pre-fetched pages could be added to the end of your free-page list, with your process's page table entries marking that they have been mapped, but are not currently valid. You need some other back-pointer lists, etc, but this is essentially the way that VMS handles its free-page list. When your process actually needs to touch any of those pre-fetched pages, if they are still on the free page list---not mapped to another process--- then you `soft fault' them from main memory into your working set. > > In any case, fast startup is a minor convenience. The important thing is > response time while running and turnaround for compute intensive jobs. > To an extent, both of these requirements are incompatible with paging > if the disk is VERY much slower than the CPU. There are no easy answers > here. You have to balance the cost of pre-fetching pages, not having those pages directly available to another process (on the free-page list), and the cost of giving your `compute intensive' jobs have such large working sets so that they only page in their initial pages and never fault again, against how the absolute loss of those pages is going to affect the page fault behaviour of your other processes. ----------------------------------------------------------------------------- Tom Morris BITNET: TOM@UNCSPHVX UNC School of Public Health UUCP : ...!mcnc!ecsvax!tpmsph ----------------------------------------------------------------------------- -- ----------------------------------------------------------------------------- Tom Morris BITNET: TOM@UNCSPHVX UNC School of Public Health UUCP : ...!mcnc!ecsvax!tpmsph -----------------------------------------------------------------------------