10

If I disable memory overcommit by setting vm.overcommit_memory to 2, by default the system will allow to allocate the memory up to the dimension of swap + 50% of physical memory, as explained here.

I can change the ratio by modifying vm.overcommit_ratio parameter. Let's say I set it to 80%, so 80% of physical memory may be used.

My question are:

  • what the system will do with the remaining 20%?
  • why is this parameter required in first place?
  • why I should not always set it to 100%?
Improve this question

2 Answers 2

Reset to default
7
+50

What the system will do with the remaining 20%?

The kernel will use the remaining physical memory for its own purposes (internal structures, tables, buffers, caches, whatever). The memory overcommitment setting handle userland application virtual memory reservations, the kernel doesn't use virtual memory but physical one.

Why is this parameter required in first place?

The overcommit_ratio parameter is an implementation choice designed to prevent applications to reserve more virtual memory than what will reasonably be available for them in the future, i.e. when they actually access the memory (or at least try to).

Setting overcommit_ratio to 50% has been considered a reasonable default value by the Linux kernel developers. It assumes the kernel won't ever need to use more than 50% of the physical RAM. Your mileage may vary, the reason why it is a tunable.

Why I should not always set it to 100%?

Setting it to 100% (or any "too high" value) doesn't reliably disable overcommitment because you cannot assume the kernel will use 0% (or too little) of RAM.

It won't prevent applications to crash as the kernel might preempt anyway all the physical memory it demands.

Improve this answer
3
  • If the kernel can take all the memory it needs anyway, what's the point of exposing this parameter (or even creating it)?
    – Dan Tumaykin
    Jul 8, 2016 at 14:14
  • Is there any official document where those parameters are explained in details? Besides kernel.org/doc/Documentation/vm/overcommit-accounting - any reference to kernel memory is missing there.
    – Dan Tumaykin
    Jul 11, 2016 at 8:40
  • 1
    I haven't found yet documentation explaining with enough details what is precisely taken into account when referring to "total address space commit". The fact the document you provide a link to states "in most situations this means a process will not be killed..." is however sufficient to confirm some memory can be used elsewhere, and the obvious consumer for this memory is the kernel.
    – jlliagre
    Jul 11, 2016 at 11:30
2

Setting the ratio to 100% will not reserve any space for file-backed pages, or in-kernel allocations such as kernel code, network buffers, etc.

In-kernel structures will be allocated regardless, causing overcommit. They're generally limited individually (e.g. there's a setting for network buffers). I don't think there's an overall limit of 50%, although an overall limit is something that's been worked on for the purpose of hosting containers.

File-backed pages are where you usually run userspace code from, so you need space for that too.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .