More or less: yes. Still, you shouldn't use incorrect terminology because at some point - language is the "coagulated thought process" - it will be in the way of your understanding. There is no "virtual swap". There is "virtual memory", which is RAM + swap space(s). It is called "virtual" because to processes it looks like one contiguous address space. To running processes there is no difference between RAM and swap. There is just "memory". Only the operating system (to be precise: the part of it which manages memory) "knows" that RAM is faster than swap and therefore tries its best to keep the most possible of the most used process memory in RAM so that paging operations (swap in/swap out) happen as rarely as possible. A process can ask for the memory it allocates to be (and remain) in RAM, but it has no way to ascertain that this is the case.

Memory reservation is in fact like reserving a table at a restaurant like jiliagre has so astutely explained: you call and say you want to come tomorrow at 20:00, table for four. They will either take or refuse your reservation but if they take it then the table cannot be used by anybody but your party, regardless of you showing up (using the table) or not. A process can reserve (=allocate) memory. Directly it will have no control over where this memory will be: RAM or swap. It can ask the OS for it being in RAM (database software does this regularly, i.e. Oracle allocates its SGA as "not swappable"), but it will have to take the OS's word for it that this in fact has happened.

There is "early" and "late" swap allocation as i have explained up in this thread. I do not know your application but maybe it uses shared memory and allocates it via the shmget() system call. This function can reserve swap space (see the SHM_NORESERVE flag) along with the allocated memory so that the process is guaranteed to have swap space should the necessity ever occur to swap it out. Alternatively it may use memory mapped I/O, the mmap() system call has an analogous functionality. If this is the case it might be sloppily programmed and thus create a memory sink: that is: memory is allocated but instead of giving it back the process "forgets" about it and allocates new memory the next time it performs the same function. (The sad truth is that this is a very common phenomenon.) This could account for the slow increase of allocated swap over time.

But even then, "swap allocated" is not the same as "swap used" which in fact comes down to: "pages swapped out" and "pages swapped in". This is why it is useless to look at swap -l's output. This only tells you if you need to increase the amount of available swap space. It will not tell you how much is actually written to/read from the swap. This is only told by the pi/po counter of vmstat (and all the other counter discussed above in detail).

I hope this helps.

bakunin