Mailinglist Archive: opensuse (5130 mails)

< Previous Next >
Re: [SLE] OT - what is top telling me?
  • From: Randall R Schulz <rschulz@xxxxxxxxx>
  • Date: Fri, 19 May 2006 17:22:00 -0700
  • Message-id: <200605191722.01076.rschulz@xxxxxxxxx>

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

< Previous Next >