swapoff fails when overcommit_memory==2
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.
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.