views:

646

answers:

3

I am trying to understand my embedded linux memory usage.

By using the top utility and the process file /proc/meminfo I can see how much virtual memory a process is using, and how much physical memory is available to the system. But it would seem for any given process the virtual memory can be very much higher than the used physical memory. As this is an embedded system memory swapping is disabled.(SwapTotal = 0)

How is linux calculating the free physical memory? As it doesn't seem to be accounting for everything allocated in the virtual memory space.

+5  A: 

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 coopted into cache as time goes on. As such, MemFree alone is a very incompete 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)

bdonlan
I think this is actually answers the crux of my confusion "...The resident size (RSIZE) is a more accurate view, as it only registers pages that are mapped in right now..." So my guess is that if any one process decided to try to allocate all of its VSIZE it would also increase the physical memory to that amount.
simon
+1  A: 

Try using htop. You will have to install it sudo apt-get install htop or yum install htop, whatever.

It will show you a more accurate representation of memory usage.

Basically, it comes down to "buffers/cache".

free -m

Look at the free column in the buffers/cache row, this is a more accurate representation of what is actually available.

             total       used       free     shared    buffers     cached
Mem:          3770       3586        183          0        112       1498
-/+ buffers/cache:       1976       1793
Swap:         7624        750       6874
simplemotives
Unfortunately it doesn't look like htop is available through Busybox on my embedded system.
simon
A: 

+1 to bdonlan I can also recommend taking a look at the proc (5) manpage which gives some useful information about the /proc file system

Martin Skøtt