mfriedel@slate.mines.colorado.edu (Friedel Michael) (04/15/91)
After I boot my NeXTstation I typed vm_stat which is supposed to list the status of the virtual memory. Here is the result: Mach Virtual Memory Statistics: (page size of 8192 bytes) Pages free: 62. Pages active: 263. Pages inactive: 970. Pages wired down: 133. "Translation faults": 9249. Pages copy-on-write: 1970. Pages zero filled: 954. Pages reactivated: 3767. Pageins: 792. Pageouts: 77. Object cache: 953 hits of 1116 lookups (85% hit rate) My system is 12meg (of which 11 meg are available, 1meg is reserved by the system at boot time for buffers, so it tells me). The swapfile has a size of 20971520 bytes after the machine is done booting. Now no matter how I twist my math, I can't come up with enough pages that justify a 20meg swapfile. So does anyone know to do the correct math, does vm_stat list incorrect statistics or does the system just forget about a few pages ? -- /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ No user serviceable part inside. Warranty void if opened modified or tampered with. No batteries included. *
benseb@nic.cerf.net (Booker Bense) (04/16/91)
In article <1991Apr15.153504.39750@slate.mines.colorado.edu> mfriedel@slate.mines.colorado.edu (Friedel Michael) writes: >After I boot my NeXTstation I typed vm_stat which is supposed to list >the status of the virtual memory. Here is the result: [ vm-stat stuff deleted ] > >My system is 12meg (of which 11 meg are available, 1meg is reserved >by the system at boot time for buffers, so it tells me). >The swapfile has a size of 20971520 bytes after the machine is done >booting. Now no matter how I twist my math, I can't come up with >enough pages that justify a 20meg swapfile. >So does anyone know to do the correct math, does vm_stat list incorrect >statistics or does the system just forget about a few pages ? > -RTFM %-)! if you have it %-(! , the swap file has a low water mark set in the file /etc/swaptab ( or something like that ). It's set so the swapfile is never shrunk to less than 20 MB. The rule of thumb is that the low water mark of the swap file should be twice the real memory. You can think of this a ``reserved space'' on your disk, so the system won't run out of swap space when it needs it. Now, for an 8 meg system 20 meg sounds a bit large. Since my 200 Meg disk is rather cramped, I'd like to ask the NeXTperts, if you think it'd be safe to set the low water mark lower ( like 16 meg ) . What kind of bad things happen to the OS when it runs out of swap disk? - Booker C. Bense prefered: benseb@grumpy.sdsc.edu "I think it's GOOD that everyone NeXT Mail: benseb@next.sdsc.edu becomes food " - Hobbes
bennett@mp.cs.niu.edu (Scott Bennett) (04/22/91)
In article <1991Apr15.153504.39750@slate.mines.colorado.edu> mfriedel@slate.mines.colorado.edu (Friedel Michael) writes: >After I boot my NeXTstation I typed vm_stat which is supposed to list >the status of the virtual memory. Here is the result: > >Mach Virtual Memory Statistics: (page size of 8192 bytes) >Pages free: 62. >Pages active: 263. >Pages inactive: 970. >Pages wired down: 133. >"Translation faults": 9249. >Pages copy-on-write: 1970. >Pages zero filled: 954. >Pages reactivated: 3767. >Pageins: 792. >Pageouts: 77. >Object cache: 953 hits of 1116 lookups (85% hit rate) > >My system is 12meg (of which 11 meg are available, 1meg is reserved >by the system at boot time for buffers, so it tells me). >The swapfile has a size of 20971520 bytes after the machine is done >booting. Now no matter how I twist my math, I can't come up with >enough pages that justify a 20meg swapfile. You probably have lowat=20971520 either in /etc/swaptab or /etc/rc.swap (or wherever.) That means that once your swapping/paging area has grown to at least 20MB, it will never shrink to less than 20MB. If you start up several NeXTStep applications, the swapping/paging area can *easily* grow beyond 20MB. NeXTStep apps are not small. Some apps also tend to grow while they run. Try watching how big Mathematica is from time to time during one execution. >So does anyone know to do the correct math, does vm_stat list incorrect >statistics or does the system just forget about a few pages ? > No. The problem here is a literacy problem on the part of the author(s) of vm_stat. Data General is similarly illiterate w.r.t. their AOS/VS system and probably many other vendors' software teams would also fit the bill. The confusion arising from vm_stat's output is the failure to distinguish between "pages", which are the contents of a process's address space, and "page frames", which are blocks of physical memory into which pages are placed for use. A page can be "fixed" or "wired" (depending on your dialect:-) into a page frame, which prevents the page from being paged out to free the page frame that it occupies. So, the first line of data should be Page frames free: 62. The next two lines refer to the *usage* of pages, but only of pages currently in physical memory, i.e. in page frames. I suppose one could argue that they could be labeled validly as they are, but since they can be added together along with number of free page frames to get the number of page frames in your computer, I'd like to see them labeled as shown below. Note also that they do *not* provide similar information regarding the total number of *pages* in the system, which can change from moment to moment. The number of page *frames* in the system is number of 8KB blocks left over in your hardware after the kernel has grabbed everything that it needs for permanently resident stuff. Page frames active: 263. Page frames inactive: 970. This next one *is* correctly labeled, because it refers to the *pages*, though obviously a "wired down" page is in physical memory and must therefore be tying up a page frame. Note that a page frame is a fixed and permanent object (until the next boot, at least) and thus cannot be wired or unwired because it is space, not data, and can't go anywhere anyway. Pages wired down: 133. The remainder of the vm_stat output appears to be correctly labeled. Scott Bennett, Comm. ASMELG, CFIAG Systems Programming Northern Illinois University DeKalb, Illinois 60115 ********************************************************************** * Internet: bennett@cs.niu.edu * * BITNET: A01SJB1@NIU * *--------------------------------------------------------------------* * "Spent a little time on the mountain, Spent a little time on the * * Hill, The things that went down you don't understand, But I * * think in time you will." Oakland, 19 Feb. 1991, first time * * since 25 Sept. 1970!!! Yippee!!!! Wondering what's NeXT... :-) * **********************************************************************