Re: More RAM for buffers?



In response to Kirk Strauser <kirk@xxxxxxxxxxxx>:

On Thursday 02 October 2008, Kirk Strauser wrote:

I have an AMD system with 6GB of RAM. From dmesg:

usable memory = 6428237824 (6130 MB)
avail memory = 6203797504 (5916 MB)

However, most of it is just sitting there when it looks like it could be
used for buffers or cache:

On another AMD64 machine, also with 6GB of RAM, I have:

Mem: 482M Active, 1044M Inact, 363M Wired, 3792K Cache, 214M Buf, 4023M Free
Swap: 8192M Total, 8192M Free

I can understand that on the other machine maybe inactive memory is more
beneficial than cache or buffers, but this system is just sitting there
with 4GB free (and the exact same amount of buffer memory as on the other,
which seems a little too coincidental).

inactive, cache, and buffer are all different types of "buffer".

I've never been 100% clear on the exact differences, but it basically has
to do with where the data in RAM came from. Depending on whether it was
a VM page, or a disk page will determine what bucket it goes into when
it moves out of active.

I'm fairly sure that inactive is memory used by program code. When the
program terminates, the memory is marked as inactive, which means the
next time the program starts the code can simply be moved back to
active and the program need not be reloaded from disk.

Buffer and cache memory are disk data held at different points within the
kernel. I've never been 100% clear on the difference, and I believe it
depends heavily on a thorough understanding of how the kernel works.

The other rule of thumb I've heard is that the closer memory is to the
left side of top output, the less expensive it is for the kernel to move
it to active ... inactive being the most efficient and cache requiring
the most work by the kernel ... I could be wrong, though.

I know that a lot of what I'm saying isn't authoritative, so I hope I'm
not remembering any of this wrong. I think to fully understand how it
works you'll need to read _The_Design_and_Implementation_.

--
Bill Moran
http://www.potentialtech.com
_______________________________________________
freebsd-questions@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscribe@xxxxxxxxxxx"



Relevant Pages

  • Re: Cached memory never gets released
    ... Stock linux 2.4.26 kernel. ... Due to flash bug 3M of memory gets lost due to font memory getting lost ... The output of "free" cache number steadily grows. ... longer to exhaust all of system memory with the cache. ...
    (Linux-Kernel)
  • CONFIG_PACKET_MMAP revisited
    ... I've been looking into faster ways to do packet captures and I stumbled on ... In that discussion Jamie Lokier suggested having a memory buffer that's ... shared between user and kernel space and having the NIC do DMA transfers ...
    (Linux-Kernel)
  • Re: RFC: CONFIG_PAGE_SHIFT (aka software PAGE_SIZE)
    ... but now we waste more memory on small files.... ... allowing us to increase the fundamental block size of the filesystem. ... _whole_ kernel faster. ... If I want a inode cache, it always needs to be 8k based. ...
    (Linux-Kernel)
  • Re: read vs. mmap (or io vs. page faults)
    ... :with the possible madvise) provides the kernel with more information ... L2 cache, and that is precisely what is happening when you readinto ... a fixed buffer in a loop in a C program... ... and 3 GBytes/sec uncached to main memory. ...
    (freebsd-current)
  • Re: read vs. mmap (or io vs. page faults)
    ... :with the possible madvise) provides the kernel with more information ... L2 cache, and that is precisely what is happening when you readinto ... a fixed buffer in a loop in a C program... ... and 3 GBytes/sec uncached to main memory. ...
    (freebsd-questions)