6

I've disabled memory overcommitting by setting overcommit_memory=2. Now when I tried to swapoff, I get this error:

swapoff: /dev/sda5: swapoff failed: Cannot allocate memory

But I in fact have 0 MiB in swap and lots of free memory! I tried setting overcommit_ratio to 100, but it didn't change anything.

If I temporarily set overcommit_memory=0 as is by default, I can successfully swapoff, then re-disable overcommitting.

Why such strange behavior? Is it a bug?


EDIT as asked in comments:

$ grep -E '^Mem|Commit' /proc/meminfo
MemTotal:        2044420 kB
MemFree:          751836 kB
CommitLimit:     4122112 kB
Committed_AS:    2752544 kB
  • Check if win.tue.nl/~aeb/linux/lk/lk-9.html section 9.6 helps you (setting overcommit_ration to 80). While others say, never set it beyond 100 (see serverfault.com/questions/362589/…) – ott-- Sep 5 '13 at 9:37
  • @ott-- I've tried setting it to 80, 90 and 100, but this didn't change the behavior (and used that same link you gave for reference :) ) – Ruslan Sep 5 '13 at 9:38
  • Could you post the contents of /proc/meminfo? (grep -E '^Mem|Commit' /proc/meminfo should be enough to diagnose I think, but not overly familiar with this aspect.) – Mat Sep 5 '13 at 10:27
8

As @Mat pointed out, Committed_AS > MemTotal. In other words, you already have allocated more memory than you physically have, so if you were to disable swap, you would already be over-committed. Thus, when you don't allow over-commit, you can not disable the swap until you free up some memory.

Not all of the allocated memory is actually used, which is why you still have some free memory, despite having allocated so much.

5

That is a very common confusion. There are several notions that are only loosely related.

  • Physical memory usage
  • Swap area usage
  • Virtual memory reservation
  • Virtual memory allocation

When a process allocated memory (malloc or similar), what it does is actually reserving memory. By default, Linux overcommits virtual memory so doesn't care that much about reservation and generally return successfully.

When you access reserved memory for the first time, this memory has to be backed by pages located either on RAM or on disk.

If there is not enough RAM to hold all the accessed virtual memory on RAM, the system starts to paginate (what is usually called swapping) and the performance stalls.

If processes reserve more memory than the sum of the swap area and (part of the) RAM, and your system is configured not to overcommit memory, the allocation fails. This can happen even while you have plenty of RAM free and are not using any pages on the swap area. This is the price to pay to have a system that doesn't randomly kills applications.

In your case, you have enough free virtual memory but a part of it is reserved so demand some swap area to be present which means you cannot remove the latter.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.