>>Interestingly enough, in the "allocate-swap-on-demand" camp, the most common "algorithm" I recall for deciding which process to kill was quite simple. In order to mimimise the number of processes to be killed, the OS would always kill the one with the largest memory footprint first. On a database server, you can probably guess what this will be... ...all the allocate-on-demand Unix derivations that I had first hand experience with selected processes with the largest resident set (minus IPC shared memory and mmap pages), and the most sleep. Database server processes always got whacked. I worked for a systems house that made servers SPECIFICALLY for database and most optimized for Oracle--Sequent. We, uh, preallocated swap since to us there was no such thing as a run of the mill fat, sleepy process...since that was generally an Oracle process (and background at that) anyway when you look closely ... ...ahhh, memory lane..walking down memory lane would be strong, effective medicine for the folks that are shoveling code into the Linux kernel.... ...Linux does not preallocate swap (within the page allocator) :-( -- //www.freelists.org/webpage/oracle-l