How Is The Linux Calculating Memfree

How is the Linux calculating MemFree

MemFree in /proc/meminfo is a count of how many pages are free in the buddy allocator. This buddy allocator is the fundamental unit of physical memory allocation in the kernel; however there are a lot of ways pages can be returned to the buddy allocator in time of need - for example, freeing empty SLABs, discarding cache/buffer RAM (even if this means invalidating PTEs in a running process), or as a last resort, swapping things out.

In fact, MemFree is generally controlled to be only 5-10% of total physical RAM, with any extra free RAM being co-opted into cache as time goes on. As such, MemFree alone is a very incomplete view of the overall memory situation.

As for the virtual memory (VSIZE) of a given process, this refers to the sum total of the sizes of all mapped memory segments in the process's address space. However, not all of these will be physically present - some may be paged in upon first access and as such will not register as memory in use until actually used. The resident size (RSIZE) is a more accurate view, as it only registers pages that are mapped in right now - although this may also not be accurate if a given page is mapped in multiple virtual addresses (which is very common when you consider multiple processes - shared libraries have the same physical RAM mapped to all processes that are using that library)

On linux, how should I calculate the amount of free memory from the information in /proc/mem?

Use the source luke!

free.c -- the source for the 'free' command line utility

sysinfo.c -- see the method meminfo() for an example of how /proc/meminfo is read in.

Whilst reading /proc is pretty straight forward being able to predict whether malloc is going to fail is not at all easy. As others have mentioned issues such as overcommit muddy the issue. The standard approach is to just try and allocate what you need and if you can't have it fail gracefully or work with less.

This series of articles is worth reading if you have enough time: What every programmer should know about memory.

How to calculate system memory usage from /proc/meminfo (like htop)

htop author here. These are the calculations I make to get the numbers for the green, blue and yellow bars in the memory meter:

  • Total used memory = MemTotal - MemFree
  • Non cache/buffer memory (green) = Total used memory - (Buffers + Cached memory)
  • Buffers (blue) = Buffers
  • Cached memory (yellow) = Cached + SReclaimable - Shmem
  • Swap = SwapTotal - SwapFree

In the htop source code: linux/LinuxProcessList.c and linux/Platform.c.

htop screenshot

Determine 'Free' Memory in Linux

You can use AWK to parse the output of the free command, and get a percentage.

free | grep Mem | awk '{print $4/$2 * 100}'

Linux command for percentage of memory that is free

exact total memory usage in linux that equals to system monitor

GNOME system monitor uses libgtop to retrieve memory information for various platforms. For Linux it uses sysdeps/linux/mem.c2 where the routine is as follows:

Strings like "MemTotal" are headings in /proc/meminfo.


buf->total = get_scaled(buffer, "MemTotal:");
buf->free = get_scaled(buffer, "MemFree:");
buf->used = buf->total - buf->free;
buf->shared = 0;
buf->buffer = get_scaled(buffer, "Buffers:");
buf->cached = get_scaled(buffer, "Cached:");

buf->user = buf->total - buf->free - buf->cached - buf->buffer;

The memory reported in the application is buf->user. More precisely in src/load-graph.cpp1 by:

mempercent  = (float)mem.user  / (float)mem.total;
set_memory_label_and_picker(GTK_LABEL(graph->labels.memory),
GSM_COLOR_BUTTON(graph->mem_color_picker),
mem.user, mem.total, mempercent);

How does free calculate used memory?

The title asks: "How does free calculate used memory?"

Answer: It asks the OS, which has to keep track of that to do its job.

More specifically, it asks the memory management subsystem. As sheepsimulator notes in the comments, the Linux kernel exposes all kinds OS maintained data in the /proc virtual filesystem, but every full service OS has to keep track of them kind of data, so it is a small matter to provide an API for free to use.

The question asks: "Why does this differ from adding up the VmSize reported for all processes?"

Answer: There are at least to thing going on here

  1. Linux will promise memory to a program without actually allocating it. When you do char *p=new(1024*1024*1024*sizeof(char)); the kernel doesn't go out to get you a gigabyte right away. It just says "OK", and figures it will grab it when you start using it. Thus the need for the infamous OOM killer.
  2. Dynamic libraries are shared, and a single page of real memory can be mapped into the virtual address space of more than one process.

Furthermore, your pass over the proc filesystem is not atomic.

The upshot is that the output of free more accurately reflects the use of physical memory on your machine at a given moment.

How to get the percentage of memory free with a Linux command?

Using the free command:

% free
total used free shared buffers cached
Mem: 2061712 490924 1570788 0 60984 220236
-/+ buffers/cache: 209704 1852008
Swap: 587768 0 587768

Based on this output we grab the line with Mem and using awk pick specific fields for our computations.

This will report the percentage of memory in use

% free | grep Mem | awk '{print $3/$2 * 100.0}'
23.8171

This will report the percentage of memory that's free

% free | grep Mem | awk '{print $4/$2 * 100.0}'
76.5013

You could create an alias for this command or put this into a tiny shell script. The specific output could be tailored to your needs using formatting commands for the print statement along these lines:

free | grep Mem | awk '{ printf("free: %.4f %\n", $4/$2 * 100.0) }'

get available memory in gb using single bash shell command

Just a slight modification to your own magical incantation:

awk '/MemFree/ { printf "%.3f \n", $2/1024/1024 }' /proc/meminfo

P.S.: Dear OP, if you find yourself invoking grep & awk in one line you're most likely doing it wrong ;} ... Same with invoking cat on a single file; that's hardly ever warranted.



Related Topics



Leave a reply



Submit