Linux inactive memory

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. The file /proc/kpageflags contains a 64-bit bitmap for every physical memory page, you can get a summary with 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 (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.

There is no such tool as it is completely pointless for any external program.

The only part of the system that needs to know that is the kernel's memory handler which will use it to know what to page (swap) out if it runs out of available memory.

The only related case that could cause any worries is if your swap becomes almost full. If that ever becomes the case, just increase it.

I've never seen actual problems that implied investigating on inactive memory.