Suppose, not hypothetically, that you're operating a compute server and its kernel is logging a series of messages to the effect of:

__vm_enough_memory: pid: 719830, comm: node, bytes: 221184 not enough memory for the allocation

(The PID, the 'comm:' command name, and the number of bytes will vary.)

This particular function has cropped up before , and this message from it means that you're hitting a limit on how much memory the kernel will let the process ask for under the current circumstances. Generally this means you're operating in strict overcommit mode , because it's hard (but not impossible) to get the Linux kernel to refuse to give you memory otherwise.

(In the default heuristic overcommit mode, a process has to ask the kernel for more memory in one request than it has total RAM plus swap before the kernel will turn you down. This is a pretty extreme and unlikely situation unless you have a tiny system.)

As the kernel source comment on __vm_enough_memory() says (currently here in mm/util.c ), this check is triggered when a process attempts to allocate a new 'virtual mapping' (which includes when it wants to grow one). In modern programs, this will most commonly happen through mmap() and most commonly when the program wants to allocate more dynamic memory, but this can also happen on (attempted) stack growth or growing the 'break' , which is still done by some programs in some circumstances.

Currently, there are two ways to be out of memory in __vm_enough_memory() . The first is to have no committed address space left at all, minus admin_reserve_kbytes if you're not 'root' (more or less). The second is to be a single process and to be trying to grow into the last bit of the commit limit. The details are more or less covered in the documentation for user_reserve_kbytes ; to rephrase the documentation, if you have a large process that's trying to grow, typically this will mean that the process effectively sees an overcommit limit that is 128 MBytes below the true commit limit.

(A 'large' process here is one that has 4 GBytes or more of committed address space. These days that's not necessarily a genuinely large process.)

In either case, to trigger this message in strict overcommit mode your system usually needs to already be quite close to its overall limit on committed address space. It's entirely possible for this to be a quite transient thing, if one process is allocating a burst of memory and driving up the committed address space, then stops when it hits the limit and releases a lot of memory back (perhaps because it exited due to memory allocation failure, or crashed). A short term situation like this might not show up in your metrics system .

How easily and often programs run into this error depends on how much memory they ask for at once, in a single request. The initial message was about a comparatively very small allocation (216 KBytes) and that not being available means that the system was very close to its overall commit limit at the time, even accounting for the effects of user_reserve_kbytes . By contrast, consider the following message as an extreme case:

__vm_enough_memory: pid: 870355, comm: <redacted>, bytes: 137438953472 not enough memory for the allocation

That's a request for a 128 GByte allocation. The particular server this kernel message is from only has 128 GBytes of RAM total and after overheads, has a commit limit of 122.5 GBytes, so this program's allocation is never going to succeed as long as strict overcommit is on (and this particular program appears to have a habit of asking for 128 GBytes of RAM, it shows up repeatedly in the logs with different PIDs). A program that can never succeed in its allocation is an extreme case, but obviously programs that ask for tens of gigabytes at once are more likely to reach the limit than programs that ask for, say, 64 MBytes at a time ( cf ).

(The kernel doesn't attempt to split up allocation requests and give you part of what you asked for. If you ask for a 32 GByte mmap() , you either get it all or you get nothing. If the system has strict overcommit and 20 GBytes of commit limit left, you get nothing, while the program that asked for 64 MBytes gets its 64 MBytes and can keep asking for another 64 MBytes again and again until it gets almost all of those 20 GBytes.)