Inactive memory very large?

[arp242]

I recently got a copy of `The design & implementation of the FreeBSD Operating System'.

On the subject of `inactive' memory, it has this to say:

Inactive : Inactive pages have contents that are still known, but they are not usually part of any active region. If the contents of the page are dirty, the contents must be written to backing store before the page can be reused.

And

A system usually tracks whether an object has been modified—is dirty—because it needs to save the object's contents before reusing the space held by the object. For example, in the virtual-memory system, a page in the virtual-memory cache is dirty if its contents have been modified. Dirty pages must be written to the swap area or filesystem before they are reused.

(And more to the same effect).

Now my two systems have a very large Inactive memory usage:

Mem: 333M Active, 2476M Inact, 610M Wired, 9624K Cache, 418M Buf, 494M Free
Mem: 240M Active, 1211M Inact, 262M Wired, 732K Cache, 112M Buf, 280M Free

Somehow, I find it hard to believe that my system has gigabytes of memory that need to be written to disk.

Does anyone know why this is the case? I Glanced at the vm-related code, but that didn't provide any insight in the issue ...

 

[worldi]

mmap() mentions that this can (or better, should) happen when MAP_NOSYNC is used.

 

[arp242]

That would only delay flusing to physical media, meaning there would still be gigabytes of memory which supposedly should be flushed at some time. I find it hard to believe my memory hold 2.5GB of data in memory which still needs to be flushed (it's an average desktop system, the other system a minor server).

(Also, to clarify, this isn't a programming question, it's a `I'm-trying-to-understand-FreeBSD-better' question )

 

[noobster]

If the contents of the page are dirty, the contents must be written to backing store before the page can be reused.

This is a conditional statement. Do you have reason to believe all your inactive pages are dirty?

 

[arp242]

If the contents of the page are dirty, the contents must be written to backing store before the page can be reused.

This is a conditional statement. Do you have reason to believe all your inactive pages are dirty?

It was my understanding that If they're not dirty, they should be in the Cache list?

Again, quoting from D&I of FreeBSD (emphasis added):

Cache : Cache pages have contents that are still known, but they are not usually part of any active region. If they are mapped into an active region, they must be marked read-only so that any write attempt will cause them to be moved off the cache list. They are similar to inactive pages except that they are not dirty, either because they are unmodified, since they were paged in, or because they have been written to their backing store. They can be moved to the free list when needed.

 

[Crivens]

There is a mixup what cache is here.

The memory management has "cache" which is disk contents NOT assigned to files on the file systems (inode tables, bitmaps, ...) - and "inactive" which is memory which has a "pager" assigned to it. That is from the old Mach-VM system which is beautifully object oriented. It means that the memory page has known contents (like, the binary code for /bin/sh) but the file is currently not mmapped. Should that memory be re-mapped, the pages can be re-mapped to be active. That is the cache functionality of the inactive memory has.

The memory could not belong to a file and so the pager for this is the swap pager. That would be memory for heap, stack and maybe something else. That memory has to be written to swap when the page is needed (dirty).

If the memory page for a file is dirty, that page needs to be written back to disk. But this needs not be done at the write to the page or the unmapping of the file! You may mmap() some file in the temp directory, copy stuff to the memory space and unmap the file. The changed memory page is now inactive, but dirty. Now you map the file again, maybe from some other process, and read the contents. The file is re-activated to the mapping of the new owner. Again, the memory page has not been written to storage. And if the file is unlinked at some point, the pages are removed from the inactive list - dirty or not. This way you can showel huge amounts of data from one process to some other, passing only a file name, and the data never is written to storage but only written to memory - not even copied in memory.

But if that file is not unlinked, at some point the memory manager will come around and tell the pager associated with that page to clean it up. That will make the swap pager write it out, or the file pager to write it to the file system. But the memory manager has no need to know what that pager actually is and what he actually is going to do.

The difference in the "cache" memory you posted may be that the file system just got crawled by some cron task, thus reading a lot of meta data from the disk. That data is not in the active/inactive memory queues but in it's own pool. Metadata is not memory mapped, so it can not use the default "caching" of the virtual memory system.

Hope this helps.