I was under the impression that virtual memory and swap are synonymous; the only real difference being swap describes the space and virtual memory describes the concept.

I have an odd issue with HTOP where the swap space used is only a few MB but the virtual memory in use is well over 10GB. See attachment!

I can't explain this...

Attached Thumbnails

 

I see tumblerd in the screenshot. That thing makes the thunbnails you see in the filebrowser. As soon as you open a "new" folder (or an external herddrive as I recently did), the thing charges loose eating away at just about all resource it can get its grubby little hands on. Until all the thunmnails are created, then...it falls back into the dark...
Pretty notmal, I'd say, unless thumblerd is alive all te time...

Thor

"swap" describes the physical resource that is used to map the virtual-memory space that is actually in use and "dirty."

Virtual memory values can be difficult to interpret since so much virtual memory is shared among multiple processes.

Basically, if you are looking for x + y + z = t ... don't.

@sundialsvcs, Well I read that on the HTOP website; but 11MB/10GB+ is a rather large discrepancy. What's the point in even providing functionality to calculate swap space if it is so far off?

@Thor_2.0, do I actually need it? I am not concerned with thumbnails.

Thanks.

Not for any reasonable definition of virtual memory.

If I'm reading that right, the VIRT size of a single process is 10.6GB and you have other processes with large VIRT.

So with your incorrect (common error) assumptions about what virtual memory is, that would obviously not fit.

VIRT counts all mapped portions of the process's address space. The parts of VIRT that is in swap space are only anonymous memory and generally only the part of anonymous memory that is not in that process's RES nor in the system cache.

RES is the portion of VIRT that is physically mapped to ram. Note that VIRT represents logical mappings that page by page might or might not be physically mapped at any given moment.

Logical anonymous mappings are used for the process's stack and heap and any pages of static or global variables that have been modified from compile time initialized values.

But anonymous memory for a process may be much smaller than its logical anonymous mappings. That is primarily because of "demand zero" mapping. A process typically asks for heap in far bigger chunks than it needs at the moment. Heap that has been requested but not yet used exists within VIRT as a demand zero mapping. There are other reasons for demand zero mappings, but heap is typically the big one. The pages represented by demand zero mappings don't physically exist anywhere.

Processes also have non anonymous memory. That is always included in VIRT. Any of that in physical ram it is either in the process's RES or the system wide cache. But when it is not in ram, it is also not in swap. That is a key fact missed by most people who misunderstand Linux swap. The common use for non anonymous memory is the code loaded from the executable file and .so files. So that tends to be a large fraction of VIRT when VIRT is small, but a small fraction when VIRT is large. Large VIRT usually means a lot of anonymous memory. But that isn't always the case. A program could directly map data files creating an enormous non anonymous use of VIRT.

Read what on the HTOP website?

Your misunderstanding of VIRT and swap seems to be larger than the typical, since you don't seem to be including RES.

Most people confused by this, understand that RES is a part of VIRT that is in physical ram. And this process's share of the system wide swap usage is a portion of VIRT that is not in physical ram. So they expect those two things to add up to VIRT, because they don't know how many other places parts of VIRT might be.

There are three things you need to know about this thing called "virtual" memory ...

1. First and foremost, every process thinks that it has just as much memory as it may require. But "the way the trick is done"is to realize that processes never actually use all of the memory that they require, and that they in any given period of time tend to refer to the same chunks of storage over and over. (So-called locality of reference.)
2. Processes share a lot of things, such as the gcc runtime library. How many copies of that data do you need in physical memory? Just one.
3. Even when processes share things such that they need the ability to make their own modifications to it, a separate copy needs to be made only when it is actually needed. (So-called copy on write.)

The reason why you can't "add up" virtual memory numbers is that virtual memory does not correspond directly to a physical resource. In a very real sense, virtual memory is an illusion.

There are two different issues mixed into that:

1) You can't meaningfully add VIRT across processes because you don't know how much is shared. With "copy on write" even non shareable portions of memory might be shared. More typically, it is shareable memory that is shared, but there is still no easy way to know how much it is shared.

2) Even a single process (as in the OP's example) may have VIRT larger than the total of ram plus used swap. It could even be larger than all of ram plus all of swap. Pages in VIRT might have no physical existence at all (demand zero) or might be on disk in ordinary files rather than swap.

You dont really need it as such, you'll be fine without it, but it completes your desktop experience.
You should be able to not-start it by commenting it out from the start up script(s)

Thor

I always choose swap and it works fine