Date: Sun, 02 Apr 95 17:57:40 -0700 From: Bakul Shah <bakul@netcom.com> To: Mike Pritchard <pritc003@maroon.tc.umn.edu> Cc: hackers@FreeBSD.org Subject: Re: swap space (was Re: any interest?) Message-ID: <199504030057.RAA26342@netcom13.netcom.com> In-Reply-To: Your message of "Sun, 02 Apr 95 05:30:21 CDT." <199504021030.FAA04207@mpp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > - 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 :-). I did say `modern Unixes' :-) > 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. This may be a factor for swapping whole process images but probably not for swapping out individual pages as pages that are never touched won't be swapped out. > 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. Clearly a research problem :-)/2 BTW, this is one place where having multiple threads in a single address space may be a win. > 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. Good point. I don't know the answer. Need to think about it. > > - 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? I was really talking about preallocation for *all* the processes that can ever run simulteneously -- which is what a separate swap partition is, in essence. For individual processes I agree that the swap space they need should be preallocated. > > - 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. I agree with you. Now that beellions and beelions (a slight exaggeration) have access to the kernel sources may be people will start experimenting and coming up with better algrotithms/strategies. > Just my opinions & ideas. Just wait till I get a multi-cpu Pentium clone > and want to run FreeBSD with 2+ CPUs :-)!!! Waiting... :-) Actually I have a lot to say about MP-izing traditional Unixes but I'll spare you that:-) -- bakul
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504030057.RAA26342>