As per the doc here : https://www.kernel.org/doc/Documentation/vm/overcommit-accounting
Imagine your computer's memory as a vast library, filled with countless books. When you open a book, you don't need to physically bring every book in the library to your desk. Instead, you just grab the specific book you need. Similarly, the Linux kernel uses a smart strategy called "lazy allocation" for managing memory. Instead of reserving physical memory for every virtual address, it waits until the memory is actually needed. This approach saves valuable physical memory, especially when you're working with large programs or handling multiple tasks simultaneously.
Think of it like this: when you allocate memory using functions like malloc(), you're basically reserving a spot in the library. The spot is assigned, but the actual book (the physical memory) hasn't been pulled from the shelf yet. This is where the page fault handler comes into play. When your program tries to access the allocated memory, it's like trying to read a book that's not yet available. The page fault handler steps in, finds a vacant book (a free physical page), places it on your desk (associates it with the virtual address), and allows you to read it (enables access). This efficient mechanism ensures that memory is used only when it's truly needed.
But what happens if you try to borrow too many books (allocate too much memory) and there are no more shelves left (physical memory is maxed out)?
Well, the librarian (the Linux kernel) has a last resort: the Out-Of-Memory (OOM) killer. This ruthless character identifies the least useful book borrower (the program consuming the most unnecessary memory) and unceremoniously kicks them out of the library (terminates the program) to make space for others.
So, while Linux's memory overcommit feature lets you borrow more books than the library actually has, beware the wrath of the OOM killer if you get too greedy!
You can alter the overcommit_memory parameter in Linux systems by editing the file :
/etc/sysctl.conf and use the parameter like :
vm.overcommit_memory = 0 --> always allocates memory unless the program obviously overcommits.
vm.overcommit_memory = 1 --> always allocates memory and overcommits.
vm.overcommit_memory = 2 --> does not overcommit memory allocation and the malloc() function will fail if there is no more memory.
The Committed_AS field in the /proc/meminfo file shows an estimate of how much RAM the system requires to avoid an out-of-memory condition for the current workload.
Continuing on this : RH442 ch08s08 :
"The Committed_AS field in the /proc/meminfo file shows an estimate of how much RAM the system requires to avoid an out-of-memory condition for the current workload."
The ‘/proc/meminfo‘ file is used to report the amount of free and used memory
(both physical and swap) on the system as well as the shared memory and buffers
used by the kernel.
/proc/meminfo provides valuable information about the system’s RAM usage
(utilization of run time memory)
Committed_AS: The amount of memory presently allocated on the system. The
committed memory is a sum of all of the memory which has been allocated by
processes, even if it has not been "used" by them as of yet.
If we want to learn the amount of memory eligible for allocation or already
allocated on the system, we can take a look at two data fields:
CommitLimit:
Committed_AS:
These data points demonstrate the allocation ability of the system
@Trevor Thanks for your addition.
Committed_AS is an estimated value that represents the amount of RAM and swap space required to guarantee a 99.99% probability of avoiding out-of-memory (OOM) errors for the current workload. This estimation is based on the assumption that all allocated memory will eventually be utilized, even if it is not currently in use.
I got this another valuable info here at : https://access.redhat.com/solutions/406773
Red Hat
Learning Community
A collaborative learning environment, enabling open source skill development.