Within the output of top, there are two fields, marked "buff/cache" and "avail Mem" in the memory and swap usage lines:

enter image description here

What do these two fields mean?

I've tried Googling them, but the results only bring up generic articles on top, and they don't explain what these fields signify.

3 Answers 3


top’s manpage doesn’t describe the fields, but free’s does:


Memory used by kernel buffers (Buffers in /proc/meminfo)


Memory used by the page cache and slabs (Cached and SReclaimable in /proc/meminfo)


Sum of buffers and cache


Estimation of how much memory is available for starting new applications, without swapping. Unlike the data provided by the cache or free fields, this field takes into account page cache and also that not all reclaimable memory slabs will be reclaimed due to items being in use (MemAvailable in /proc/meminfo, available on kernels 3.14, emulated on kernels 2.6.27+, otherwise the same as free)

Basically, “buff/cache” counts memory used for data that’s on disk or should end up there soon, and as a result is potentially usable (the corresponding memory can be made available immediately, if it hasn’t been modified since it was read, or given enough time, if it has); “available” measures the amount of memory which can be allocated and used without causing more swapping (see How can I get the amount of available memory portably across distributions? for a lot more detail on that).


Just to clarify a bit, buffers refers to data that is being written -- that memory cannot be reclaimed until the write is complete.

Cache refers to data that has been read -- it is kept around in case it needs to be read again, but can be immediately reclaimed since it can always be re-read from disk.

  • That's not really what it means here. /proc/meminfo has a field for Writeback specifically. There is a separate field Buffers, and that is what is shown as buffers in free -w. A common reason for Buffers memory usage is shown here: "30% of RAM is “buffers”. What is it?"
    – sourcejedi
    Feb 13, 2019 at 16:27
  • From this (access.redhat.com/solutions/406773) I take it that Writeback is that portion of Buffers that has not yet been written to disk. Or are you saying something else?
    – WallStProg
    Feb 15, 2019 at 14:57
  • That description would be misleading. Buffers is (now) a part of the page cache; it is not counted in Cached, but it is counted as part of Active(file) + Inactive(file). See comments on Stephen Kitt's answer. Dirty is the part of the page cache which has been written to, and so eventually needs writing back to disk. Writeback does not include Dirty. Therefore, Writeback is not a portion of the value of Buffers.
    – sourcejedi
    Feb 15, 2019 at 15:05
  • 1
    What Buffers actually means is the page cache associated with the block device. Some filesystems use this internally; others don't use it at all. /goes to fixup my answer on the "30% of my RAM is buffers" question.
    – sourcejedi
    Feb 15, 2019 at 15:40

The canonical source of this information is /usr/src/linux/Documentation/filesystems/proc.rst

Buffers: Relatively temporary storage for raw disk blocks shouldn't get tremendously large (20MB or so) Cached: in-memory cache for files read from the disk (the page cache). Doesn't include SwapCached.

You can also find some more details here.

The Linux Page Cache ("Cached:" from meminfo ) is the largest single consumer of RAM on most systems. Any time you do a read() from a file on disk, that data is read into memory, and goes into the page cache(1.).
The buffer cache ("Buffers:" in meminfo) is a close relative to the dentry/inode caches.

Or analysis the source code like this.

The amount of buffers is the return value of function nr_blockdev_pages(void)

long nr_blockdev_pages(void)
        struct block_device *bdev;
        long ret = 0;
        list_for_each_entry(bdev, &all_bdevs, bd_list) {
                ret += bdev->bd_inode->i_mapping->nrpages;
        return ret;

The amount of cached:

global_page_state(NR_FILE_PAGES) – total_swapcache_pages – i.bufferram

You must log in to answer this question.