Carlos, On Friday 19 May 2006 16:27, Carlos E. R. wrote:
The Saturday 2006-05-20 at 00:47 +0200, I wrote:
The Thursday 2006-05-18 at 08:49 +0200, Per Jessen wrote:
No-one's got any suggestions regarding this discrepancy??
I thought about it, but I don't really know what happens; I have noticed similar numbers in mine. I have a guess: that "VIRT" shows the assigned or memory, but maybe it has holes, or it hasn't been "located". Poor choice of words... I don't think I can express my idea well tonight.
I got another idea; I don't know if Linux does this, but I remember Windows did, and perhaps still does. Windows can completely discard unused code sections of programs and libraries; I don't mean swaping memory out, but discard. If that part of the code is needed again, it is reloaded from the original executable file. This way, it needs less swap file space.
Yes. Pure code pages don't get sent to swap, they're read from the original executable file directly and abandoned instead of being swapped out when the RAM page is needed for another purpose.
Can Linux do a similar thing? Using swap space would be faster (when reading back), I think, but if it does it could also help explain the discrepancy you found in top.
Definitely. The linkers play along by aligning code boundaries in .so files on convenient boundaries (512 bytes at the smallest, but probably larger) so data can be sent directly from disk via DMA to the RAM location that is set up in the page tables to be present at the proper place in the application's virtual address space. The only speed advantage for swap (assuming it uses the same disks as the file system(s)) is guaranteed physical contiguity of logically contiguous pages. But that's true in the file system unless (or until) there's fragmentation of the executable or shared object files.
-- Cheers, Carlos Robinson
Randall Schulz