>Windoze 95 does this, and you know how that performs :-), NT does it to
>som extent in the sense that it can grow it's swap to a preset limit.
>There are two problems, first of all a runaway process will not only use
>up VM, but also your disk. If the disk is your root FS or /tmp fs that
>could cause serious problems. Second is the fragmentation you already
>mentioned, a progam using large amounts of memory and writing large files
>will write file, swap, file, swap or some such pattern, causing swap and
>files to be interleaved instead of contiguous.
The fragmentation problem is easily solved. Just use large blocks for the swap file as OS/2 does. The architecture of OS/2 specifies that swap files will be allocated in blocks (and the file system interface allows the FS drivers to know it's a swap file and that blocks should be allocated contiguously if possible). Current implementations of OS/2 only allow the swap file to be grown in 1meg chunks and the design of the OS allows for other sizes (future versions may use 4meg as computers are so much bigger now than they were when OS/2 2.0 was released).
This won't totally remove fragmentation, but it'll reduce it so much that these problems with programs that write large files should disappear.
>One thing that will give you a performance hit is the shrinking of the
>swap file. When used swap space allows for shrinking it has to be
>reorganized because the unused space will almost never be located at the
>end of the swap file. On windoze 95 this causes serious thrashing of the
>disk for periods ranging from 1 to 10 seconds. The system is almost
>unusable during this period. On a multiuser system this is undesirable.
The shrinking of the swap file doesn't necessarily have to give that much of a performance hit. I am sure that you could devise some better algorithms than those used in Win95. Why not just avoid directly trying to compress the swap file, but slowly page in the data at the end of the swap file when the system is idle? If the page-in process was only run when the disk was not being used much then it shouldn't impact performance at all. The only difficult part is determining accurately when the disk isn't being used much (the hard drive is almost never idle on any serious UNIX system).
Russell Coker