Date: Sun, 2 Apr 1995 05:30:21 -0500 (CDT) From: Mike Pritchard <pritc003@maroon.tc.umn.edu> To: bakul@netcom.com (Bakul Shah) Cc: hackers@FreeBSD.org Subject: Re: swap space (was Re: any interest?) Message-ID: <199504021030.FAA04207@mpp.com> In-Reply-To: <199504020817.AAA05418@netcom23.netcom.com> from "Bakul Shah" at Apr 2, 95 00:17:19 am
next in thread | previous in thread | raw e-mail | index | archive | help
> Swap space is another thing that is worth taking a fresh > look at. Some things to consider.... > > - We no longer (or hardly ever) swap out entire process > images like we used to. [`We' == all moderen Unixes] I used to work for Cray Research, and when I left (1.5 years ago), we were still swapping entire procs, but then again we didn't have virtual memory :-). We were working on doing partial swaps of procs, though. I was Mr. Swap back then. > - Most of the traffic is paging traffic and (as far as I > remember) the clock algorithm does not care for which page > belongs to which process. > > - Many more page-ins occur, compared to page-outs. > Optimizing swap placement to improve pagein times ought to > help the overall performance. On slower disks this is a factor. Then again, choosing the right procs to swap out in the first place helps too. Another thing to look at is the profile of the proc being swapped out. Can the image be compressed? I've seen in the past that some of the more "scientific" type procs (ok, ok, F77 programs, or programs by people who have never heard of "malloc" and have HUGE arrays defined right from the start of their program that never get filled until the last few minutes of the program run) tend to contain a lot of pages of zero that could be written as compressed files, or as sparse files in a file system swap concept. > [except when they are used as a group -- but it is > difficult to know at kernel level which processes > constitute a cooperating group of processes.] Yes/no, and as you state, it is difficult to determine which processes are really "cooperating". E.g. "x | y". Both of those processes are related, and swapping of either can greatly affect the other, depending on the application. > - May be pages that constitute the working set of a process > ought to be swapped together? The idea is that you will > need them together and if a few are paged out the process > will be blocked waiting for them. The problem here is that you can run into a SERIOUS deadlock/performance problem on a busy system if you are never able to swap the "working set" back in. Believe be...been there, done that. > - Do we really need to preallocate all the swap space we > may ever need? That seems like a poor use of space. I've always felt that swap space was kinda a waste, but on a very busy system if you shared that space with something else (/tmp?), your swapping algorithms changes a lot. What happens if someone gobbles up all that space and now you have no place to swap that huge process? Typically, you choose different swapping strategies depending on memory & swap space. Having a "dynamic" swap space really throws a wrench into things. I'm not saying it can't be done, but have fun if you really want to try it out and get it totally working. > - As long as there is backing store for the total amount of > virtual space allocated, everyone can make progress. > Beyond that why should the swap space resource be treated > any different from normal files? Again, you might choose a different scheduling/swap strategy depending on how much swap space you think/know you have available. > - Perhaps a soft lower bound and hard upper bound for how > much space can be used for swapping may be better? > > - Perhaps contiguous swap-space allocation *per* process may > be good enough? Has anyone done any benchmarks lately to see how much performance hit there is for having non-contiguous disk allocations? This used to be a big factor on older/slower DOS type disks, but I guess I've gotten spoiled by the larger disks & controllers we had on our Cray's and other mainframes that I've worked on that kinda made this a moot point. As someone was asking earlier, striped disks can help improve this, even if you are not using any type of a RAID strategy. Write one track to disk 1, the next to disk 2, the next to disk 3, the next to disk 1, and so on can really help performance. I'm sure a well thought out striping system for FreeBSD would really help out server type machines. I would like to see FreeBSD file systems span multiple slices, without regard to which physical disk the slice resides on. > - Unifying swap and file models ought to help each other. > For instance, contiguous and/or pre-allocation of files > can be useful for certain applications. Conversely, > growing a swap space can be useful too. Also, by keeping > a swap-file per process, you can use all the standard > tools on them (+ follow the standard protection model). Preallocation of space has been around on the Cray for a while. You were never guaranteed that the space was contiguous (but being contiguous was never an issue there), just that the space was there and that you could allocate it after calling the appropriate system call. This really helps (braindead, IMHO) database type applications. > - Fundamentally there is nothing different about swap space > compared to a normal file. One can think of a typical > Unix process image as consisting of a numbe of files (or > file segments): text, data, bss & stack. You are right. Swap space is really just a file allocated by the kernel, but without the overhead of the filesystem (or with other overhead depending on the operating system :-). > My opinions & ideas (+ some ideas borrowed from others). I > throw them out to stir up some interesting discussion. > > -- bakul Just my opinions & ideas. Just wait till I get a multi-cpu Pentium clone and want to run FreeBSD with 2+ CPUs :-)!!! -- Mike Pritchard pritc003@maroon.tc.umn.edu "Swap on that disk. Really fast. If something slows you down, switch to another disk!"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504021030.FAA04207>