brent%sprite.Berkeley.EDU@ginger.berkeley.edu (Brent Welch) (03/04/89)
Yup, SunOS 4.0 uses mapped files. If you are not careful in the implementation you can swap out processes in favor of files, especially during copy of a large file. By mapping the file into your address space you end up walking through memory, paging away. There are heuristics that you can build into your VM system to account for this. I'm not sure how mature the 4.0 implementation is, however, and if they have done anything along these lines, yet. In Sprite we have potentially the same problem, not because we use mapped files (which we don't) but because we allow the file system cache to grow upon demand. VM and FS negotiate over free pages, and they compare LRU times when a page needs to be replaced. We ended up adding a bias against the file system so that recently touched VM pages are not discarded in favor of new FS pages. By setting the bias to 600 seconds, for example, any VM page touched within the last 10 minutes won't be pitched to make room for a FS page. Instead, FS has to recycle one of its own pages. Mike Nelson ran some benchmarks pitting a large sort against a large gdb process and found that *both* processes ran faster with a bias against FS. The reduced paging activity actually helped the sort as well as the process with the large VM image. Brent Welch University of California, Berkeley brent%sprite@ginger.Berkeley.EDU
jbm@eos.arc.nasa.gov (Jeffrey Mulligan) (03/08/89)
by pixar!rta@ucbvax.berkeley.edu (Rick Ace): > 4. Same system. > Experimental load: cp largefile newfile > Now the window system bogs down real bad. Typing ^Z in the > window where the "cp" was running had no effect! Trying to > open or close other windows experienced extreme delays. > ...Have you noticed this type of behavior on your systems?... Since we have converted to 4.0, I have had programs become un-^Z-able, un-^C-able. These turned out to be 60-second core dumps. Not surprisingly, these problems are more severe on our 4Mb sun-3's. It is too bad that the system says "Segmentation error; core dumped" at the END of the core dump, instead of saying "Segmentation violation; dumping core" and the beginning of the core dump. At least then you would know what was happening. And yes, when these core dumps are going on the window system is not merely sluggish, it is dead to the world. Jeff Mulligan (jbm@aurora.arc.nasa.gov) NASA/Ames Research Ctr., Mail Stop 239-3, Moffet Field CA, 94035 (415) 694-6290 [[ I don't find that surprising. Dumping "core" is something that the kernel does, and it tends to inhibit all normal user process activity while it is going on. Since a workstation has to dump to an NFS or nd file system, it makes it only worse. --wnl ]]