> once a program allocates itself some RAM, it *SURE* doesn't seem to want to give it up.
A program's allocations tend to be too fragmented, so functions like free() usually do not even try to give the memory back to the OS.
> Of course, this is really hard to be sure of, because any long time linux user will tell you that the memory columns in ps don't really mean anything useful, and when you dig further - it's hard to be sure the *KERNEL* knows what memory belongs to who - although it does do a good job of cleaning up after the application crashes, so it knows *SOMETHING*.
The biggest problem are shared libraries; the kernel knows who uses them, but it's not clear how their memory should be counted. (Which process gets charged for that memory? And when it exits, does the memory usage of the other processes suddenly increase?)
> What was the hard drive doing thrashing, since there was no designated swap for memory to be pushed off to temporarily?
Normal data can get swapped out, if there is swap.
Code from executable files does not need to be saved to swap because it can be reloaded from the executable file. In other words, every executable file is a read-only swap file.