Originally posted by svanheulen
You have real physical memory. You have swap (disk backed) memory. You have virtual memory which represents both combined. Presumably the kernel can even provide memory beyond the sum of the physical and swap memory if it maps unused pages to a table of memory ranges used to record non-backed, unused virtual pages.
You've also got memory pages shared between multiple apps. You've got memory that is considered part of the executable data and code regions. You've got stack and heap memory (are tools like top and htop even able to see the difference?).
htop seems to show the same data for threads belonging to a process and the process itself. So I guess threads can't have their own memory. I don't know.
You've also got shared libraries that that I guess use some type of shared memory which is probably shown in a virtual address space which may or may not be backed by physical memory, but is definitely used by multiple apps so can't be fairly considered to be part of the memory footprint of any individual app.
There's probably copy-on-write, memory-saving shenanigans going on too which likely further skews the numbers.
My current approach to managing my unending confusion in this matter is three fold:
- Put lots of physical memory in my machine.
- Try and use apps that claim to be lightweight when I don't need the heavy weight equivalents (eg use Transmission instead of Vuze for torrenting and Audacious instead of Rhythmbox for music).
- Pray daily to the silicon gods that they do not send their reaper to reap my processes. (They say his name is the OOM Killer and he acts without mercy and without consent)
Comment