mike@RICE.ARPA (Mike Caplinger) (05/15/85)
Our experience has been that we run out of swap space much sooner under 4.2 than we did under 4.1, with swap areas of the same size. This has been "explained" by the fact that the 4.2 swap area allocation scheme causes increased fragmentation. However, careful examination of 4.1 and 4.2 source reveals that the VM code has changed only little between the two versions. In particular, the parameters DMMIN and DMMAX, constants in 4.1, have become variables in 4.2. But they are immediately set to what seem to be the same values. (I'm on shaky ground here, since the only 4.1 source I could find may have had these parameters' values changed.) I find no sign of a modification that might cause more fragmentation under 4.2. Does anybody know what difference between 4.1 and 4.2 might have caused more fragmentation? I am assuming that the move to 4K blocks isn't responsible, and doesn't affect the treatment of the swap device. If I'm wrong, then is there some easy way (short of changing DMMAX, etc.) to reduce the fragmentation? By the way, experiments indicate that with a 16.7 meg swap area, the system can't create a 0.5 meg process when there is slightly more than 10 meg in existing processes. - Mike p.s. Why do I ask? We have several VAXen with single RA81s and its standard, 16.7 meg swap area. Last semester the students using one of the machines found they could only run 3 Modula compiles before running out of swap area, so they evolved a scheme of passing three Coke cans around the terminal room; only people with one of these cans was allowed (via peer pressure) to do a compile. Needless to say, I would prefer to have this kludge go away.
chris@umcp-cs.UUCP (Chris Torek) (05/15/85)
At the expense of a much larger swap map, you can reduce DMMAX and increase NDMAP accordingly; that will reduce lossage due to large chunks of swap used for small chunks of memory. Without looking at the pstat source, I would guess that the "wasted" statistic is generated by finding such chunks and figuring out what would be recovered if all blocks were of size DMMIN. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@maryland