Return to Answer

"buffers" are reclaimable under memory pressure. So it is similar to the page cache ("cache" column); not a big cause for concern. The "buffers" value can be small or large, it depends what your system is doing :-). We can find several types of cache counted here.

The buffer cache is literally the page cache for the block device. Linux just reports these separately.[*] You could notice "buffers" usage when programs read/write the block device node, e.g. dd status=progress if=/dev/sda of=/dev/null. Apparently people also notice it with DVD playback software.

For proof, see: 30% of RAM is "buffers". What is it?

If you have not been accessing the block device node, your "buffers" are probably all filesystem metadata. Filesystems use the buffer cache internally as a convenience. They make sure it never duplicates the file data - file contents - which is stored in the main page cache. Exactly what the filesystem uses the buffer cache for - if anything - varies depending on the filesystem.

On a machine with a small amount of physical RAM, I noticed "buffers" can look high, when I have ext3/ext4 filesystems. This was because writes to the journal go through the buffer cache. (See link above). ext3/4 filesystems also store directory contents in the buffer cache.

Secondly, "buffers" shown by the free command also include SReclaimable, meaning reclaimable slabs. (Demonstrated here: The Right Way to Monitor Linux Memory, Again).

Slab memory is not part of the page/buffer cache. However it is convenient to count them together. They are both reclaimable, and the main (only?) use of reclaimable slabs is for filesystem caching. For example file metadata (inodes) and path lookups (dentry's) are cached in reclaimable slabs. "Reclaimable slab memory [can] take up a large fraction of system memory on mostly idle systems with lots of files."

You can see the raw Buffers and SReclaimable values in cat /proc/meminfo. You can also run slabtop to see the list of slabs. AFAICT, slabtop doesn't give stats on slabs as reclaimable or not. But you can usually guess, and if there is some suspicious slab I guess you can look it up by name.

[*] For the purposes of this answer, "buffer cache" is the cache counted by Buffers in /proc/meminfo. However other sources may refer to the entire page cache as a unified buffer cache. If you want the historical explanation, see the first link.

Also Linux developers may have used "buffer cache" to mean different things, when they were squabbling about filesystem implementations.

"buffers" are reclaimable under memory pressure. So it is similar to the page cache ("cache" column); not a big cause for concern. The "buffers" value can be small or large, it depends what your system is doing :-). We can find several types of cache counted here.

The buffer cache is literally the page cache for the block device. Linux just reports these separately.[*] You could notice "buffers" usage while programs read/write the block device node, e.g. dd status=progress if=/dev/sda of=/dev/null. Apparently people also notice it when running a DVD player program.

For proof, see: 30% of RAM is "buffers". What is it?

If you have not been accessing the block device node, your "buffers" are probably all filesystem metadata. Filesystems use the buffer cache internally as a convenience. They make sure it never duplicates the file data - file contents - which is stored in the main page cache. Exactly what the filesystem uses the buffer cache for - if anything - varies depending on the filesystem.

On a machine with a small amount of physical RAM, I noticed "buffers" can look high, when I have ext3/ext4 filesystems. This was because writes to the journal go through the buffer cache. (See link above). ext3/4 filesystems also store directory contents in the buffer cache.

Secondly, "buffers" shown by the free command also include SReclaimable, meaning reclaimable slabs. (Demonstrated here: The Right Way to Monitor Linux Memory, Again).

Slab memory is not part of the page/buffer cache. However it is convenient to count them together. They are both reclaimable, and the main (only?) use of reclaimable slabs is for filesystem caching. For example file metadata (inodes) and path lookups (dentry's) are cached in reclaimable slabs. "Reclaimable slab memory [can] take up a large fraction of system memory on mostly idle systems with lots of files."

You can see the raw Buffers and SReclaimable values in cat /proc/meminfo. You can also run slabtop to see the list of slabs. AFAICT, slabtop doesn't give stats on slabs as reclaimable or not. But you can usually guess, and if there is some suspicious slab I guess you can look it up by name.

[*] For the purposes of this answer, "buffer cache" is the cache counted by Buffers in /proc/meminfo. However other sources may refer to the entire page cache as a unified buffer cache. If you want the historical explanation, see the first link.

Also Linux developers may have used "buffer cache" to mean different things, when they were squabbling about filesystem implementations.

"buffers" are reclaimable under memory pressure, similar to the page cache ("cache" column). So this does not demonstrate a problem. The "buffers" value can be small or large, it depends what your system is doing :-). We can identify a few different types of uses.

The buffer cache is literally the page cache for the block device. Linux just reports these separately.[*] You could notice "buffers" usage when programs read/write the block device node, e.g. dd status=progress if=/dev/sda of=/dev/null. Apparently people also notice it with DVD playback software.

Link: 30% of RAM is "buffers". What is it?

If you have not been accessing the block device node, your "buffers" are probably all filesystem metadata. Filesystems use the buffer cache internally as a convenience. They make sure it never duplicates the file data - file contents - which is stored in the main page cache. Exactly what the filesystem uses the buffer cache for - if anything - varies depending on the filesystem.

On a machine with a small amount of physical RAM, I noticed "buffers" can look high, when I have ext3/ext4 filesystems. This was because writes to the journal go through the buffer cache. (See link above). ext3/4 filesystems also store directory contents in the buffer cache.

Secondly, "buffers" shown by the free command also include SReclaimable, meaning reclaimable slabs. (Demonstrated here: The Right Way to Monitor Linux Memory, Again).

Slab memory is not part of the page/buffer cache. However it is convenient to count them together. They are both reclaimable, and the main (only?) use of reclaimable slabs is for filesystem caching. For example file metadata (inodes) and path lookups (dentry's) are cached in reclaimable slabs.  "Reclaimable slab memory [can] take up a large fraction of system memory on mostly idle systems with lots of files.".

You can see the raw Buffers and SReclaimable values in cat /proc/meminfo. You can also run slabtop to see the list of slabs. AFAICT, slabtop doesn't give stats on slabs as reclaimable or not. But you can usually guess, and if there is some suspicious slab I guess you can look it up by name.

[*] For the purposes of this answer, "buffer cache" is the cache counted by Buffers in /proc/meminfo. However other sources may refer to the entire page cache as a unified buffer cache. If you want the historical explanation, see the first link.

Also Linux developers may have used "buffer cache" to mean different things, when they were squabbling about filesystem implementations.

"buffers" are reclaimable under memory pressure. So it is similar to the page cache ("cache" column); not a big cause for concern. The "buffers" value can be small or large, it depends what your system is doing :-). We can find several types of cache counted here.

The buffer cache is literally the page cache for the block device. Linux just reports these separately.[*] You could notice "buffers" usage when programs read/write the block device node, e.g. dd status=progress if=/dev/sda of=/dev/null. Apparently people also notice it with DVD playback software.

For proof, see: 30% of RAM is "buffers". What is it?

If you have not been accessing the block device node, your "buffers" are probably all filesystem metadata. Filesystems use the buffer cache internally as a convenience. They make sure it never duplicates the file data - file contents - which is stored in the main page cache. Exactly what the filesystem uses the buffer cache for - if anything - varies depending on the filesystem.

On a machine with a small amount of physical RAM, I noticed "buffers" can look high, when I have ext3/ext4 filesystems. This was because writes to the journal go through the buffer cache. (See link above). ext3/4 filesystems also store directory contents in the buffer cache.

Secondly, "buffers" shown by the free command also include SReclaimable, meaning reclaimable slabs. (Demonstrated here: The Right Way to Monitor Linux Memory, Again).

Slab memory is not part of the page/buffer cache. However it is convenient to count them together. They are both reclaimable, and the main (only?) use of reclaimable slabs is for filesystem caching. For example file metadata (inodes) and path lookups (dentry's) are cached in reclaimable slabs. "Reclaimable slab memory [can] take up a large fraction of system memory on mostly idle systems with lots of files."

You can see the raw Buffers and SReclaimable values in cat /proc/meminfo. You can also run slabtop to see the list of slabs. AFAICT, slabtop doesn't give stats on slabs as reclaimable or not. But you can usually guess, and if there is some suspicious slab I guess you can look it up by name.

[*] For the purposes of this answer, "buffer cache" is the cache counted by Buffers in /proc/meminfo. However other sources may refer to the entire page cache as a unified buffer cache. If you want the historical explanation, see the first link.

Also Linux developers may have used "buffer cache" to mean different things, when they were squabbling about filesystem implementations.

As suggested in the other answer, the "buffers" are reclaimable under memory pressure, in the same way as the page cache ("cache" column).

The buffer cache is literally the page cache for the block device. Linux just reports it separately. You could notice "buffers" usage when programs read/write the block device node, e.g. dd status=progress if=/dev/sda of=/dev/null. Apparently people also notice it with DVD playback software.

Link: 30% of RAM is "buffers". What is it?

If you have not been accessing the block device node, your "buffers" are probably all filesystem metadata. Filesystems use the buffer cache internally as a convenience. They make sure it never duplicates the file data - file contents - which is stored in the main page cache. Exactly what the filesystem uses the buffer cache for - if anything - varies depending on the filesystem.

On a machine with a small amount of physical RAM, I noticed "buffers" can look high, when I have ext3/ext4 filesystems. This was because writes to the journal go through the buffer cache. (See link above). ext3/4 filesystems also store directory contents in the buffer cache.

Secondly, "buffers" shown by the free command also include SReclaimable - reclaimable slabs. (Demonstrated here: The Right Way to Monitor Linux Memory, Again).

Slabs are not part of the page/buffer cache. However it is convenient to count them together. They are both reclaimable, and the main (only?) use of reclaimable slabs is for filesystem caching. For example file metadata (inodes) and path lookups (dentry's) are cached in reclaimable slabs. "Reclaimable slab memory [can] take up a large fraction of system memory on mostly idle systems with lots of files.".

You can see the raw Buffers and SReclaimable values in cat /proc/meminfo. You can also run slabtop to see the list of slabs. AFAICT, slabtop doesn't give stats on slabs as reclaimable or not. But you can usually guess, and if there is some suspicious slab I guess you can look it up by name.

"buffers" are reclaimable under memory pressure, similar to the page cache ("cache" column). So this does not demonstrate a problem. The "buffers" value can be small or large, it depends what your system is doing :-). We can identify a few different types of uses.

The buffer cache is literally the page cache for the block device. Linux just reports these separately.[*] You could notice "buffers" usage when programs read/write the block device node, e.g. dd status=progress if=/dev/sda of=/dev/null. Apparently people also notice it with DVD playback software.

Link: 30% of RAM is "buffers". What is it?

If you have not been accessing the block device node, your "buffers" are probably all filesystem metadata. Filesystems use the buffer cache internally as a convenience. They make sure it never duplicates the file data - file contents - which is stored in the main page cache. Exactly what the filesystem uses the buffer cache for - if anything - varies depending on the filesystem.

On a machine with a small amount of physical RAM, I noticed "buffers" can look high, when I have ext3/ext4 filesystems. This was because writes to the journal go through the buffer cache. (See link above). ext3/4 filesystems also store directory contents in the buffer cache.

Secondly, "buffers" shown by the free command also include SReclaimable, meaning reclaimable slabs. (Demonstrated here: The Right Way to Monitor Linux Memory, Again).

Slab memory is not part of the page/buffer cache. However it is convenient to count them together. They are both reclaimable, and the main (only?) use of reclaimable slabs is for filesystem caching. For example file metadata (inodes) and path lookups (dentry's) are cached in reclaimable slabs. "Reclaimable slab memory [can] take up a large fraction of system memory on mostly idle systems with lots of files.".

You can see the raw Buffers and SReclaimable values in cat /proc/meminfo. You can also run slabtop to see the list of slabs. AFAICT, slabtop doesn't give stats on slabs as reclaimable or not. But you can usually guess, and if there is some suspicious slab I guess you can look it up by name.

[*] For the purposes of this answer, "buffer cache" is the cache counted by Buffers in /proc/meminfo. However other sources may refer to the entire page cache as a unified buffer cache. If you want the historical explanation, see the first link.

Also Linux developers may have used "buffer cache" to mean different things, when they were squabbling about filesystem implementations.