There are cases where looking at inactive memory is interesting, a high ratio of active to inactive memory can indicate memory pressure for example, but that condition is usually accompanied by paging/swapping which is easier to understand and observe. Another case is being able to observe a ramping up or saw-tooth for active memory over time – this can give you some forewarning of inefficient software (I've seen this with naïve software implementations exhibiting O(n)
type behavior and performance degradation).
The file /proc/kpageflags
contains a 64-bit bitmap for every physical memory page, you can get a summary with the program page-types
which may come with your kernel.
Your understanding of active and inactive is incorrect however
- active memory are pages which have been accessed "recently"
- inactive memory are pages which have not been accessed "recently"
"recently" is not an absolute measure of time, but depends also on activity
and memory pressure (you can read some of the technical details in the free book Understanding the Linux Virtual Memory Manager, Chapter 10 is relevant here), or the kernel documentation (pagemap.txt).
Each list is stored as an LRU (more or less). Inactive memory pages are good candidates for writing to the swapfile, either pre-emptively (before free memory pages are required) or when free memory drops below a configured limit and free pages are (expected to be imminently) needed.
Either flag applies to pages allocated to running processes, with the exception of persistent or shared memory all memory is freed when a process exits, it would be considered a bug otherwise.
This low level page flagging doesn't need to know the PID (and a memory page can have more than one PID with it mapped in any case), so the information required to provide the data you request isn't in one place.
To do this on a per-process basis you need to extract the virtual address ranges from /prod/PID/maps
, convert to PFN (physical page) with /proc/PID/pagemap
, and index into /proc/kpageflags
. It's all described in pagemap.txt
, and takes about 60-80 lines of C. Unless you are troubleshooting the VM system, the numbers aren't very interesting. One thing you could do is count the inactive and swap-backed pages per-process, these numbers should indicate processes which have a low RSS (resident) size compared with VSZ (total VM size). Another thing might be to infer a memory leak, but there are better tools for that task.