Yesterday, James R. Van Zandt gleaned this insight:
>
> Derek Martin <[EMAIL PROTECTED]> wrote:
> >> total: used: free: shared: buffers: cached:
> >> Mem: 64524288 41836544 22687744 25706496 9859072 15622144
> ...
> >I just had a discussion about that very topic with one of our kernel
> >weenies last week. You're almost perfect, if I understood him
> >correctly... Shared refers to the number of bytes being used by more than
> >one process (not necessarily shared libraries, can also be text pages of a
> >program with multiple instances). Buffers refer to I/O buffers (any
> >buffered I/O), while cached refers specifically to disk buffer cache.
> >The numbers do not add up to 100%, and will overlap.
>
> That's pretty much what the terms would lead me to think. The "disk
> cache" would be an area of memory that holds the same information as
> part of the disk. Any disk I/O buffers would qualify as cache. They
> hold the same data as the disk, either because it was just read from
> disk, or else some program has told the kernel to write it to disk.
> (The kernel might not have gotten around to it yet.) Other sorts of
> I/O buffers, as for network I/O, would not count as cache. Which
> would make me expect that "cached" should be a strict subset of
> "buffers". Yet, in the above case, "cached" is larger. What am I
> missing?
I/O buffers != disk cache. I'm not a kernel hacker (Hey, new acronym!
IANAKH -- like we needed another), but here goes:
The standard C library has buffered I/O routines that write to buffers in
memory (such as fprintf and fwrite), and only when the buffer is filled
does it flush the buffer to disk or whatever. At that point, but not
before, it would potentially become part of the disk cache, IF the I/O
stream pointed to a file on disk, and depending on how the caching
algorithm is written. Similar operations occur on the read end as well.
When fscanf or fread are called, the kernel will read in a block or maybe
blocks from a disk file, and stick them in a buffer. The process then
actually copies the data from the buffer, into some variable or another
buffer that it has allocated for itself. When the process has read past
the buffered blocks, it will do it again. I/O buffers are associated with
open streams in the standard C library.
Unbuffered I/O, such as from the read and write system calls, does not go
into an I/O buffer. The kernel writes each write directly to the device
and such, without using an I/O buffer. However, this data may still
become part of the buffer cache if the device is a block device (like a
disk), though no I/O buffer was used.
The system will attempt to cache as much of the recently accessed portion
of the disk as it can cache efficiently in most of the rest of memory, in
order to speed up access to it. This has nothing to do with I/O buffers,
other than that once the stream's buffer has been flushed, it will likely
become a part of the disk cache. The two are distinct, possibly resulting
in more than one copy of the data in memory while the system is reading
from a stream. But perhaps not -- maybe they use the same pages when
possible, I don't know.
If I've got this wrong, someone please correct me. But that's my
understanding of how it works.
--
---------------------------------------------------------------
Derek D. Martin | Unix/Linux Geek
[EMAIL PROTECTED] | [EMAIL PROTECTED]
---------------------------------------------------------------
**********************************************************
To unsubscribe from this list, send mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**********************************************************
