i will try this cause it's fun to review (as always i will be more or less correct, most likely less than more)
i don't have that utility so i can't speak to it specifically
like you figured this stuff is memory structures within the kernel
first none of this stuff accounts for the two level paging tables which account for permanent use of some of your memory
user virtual memory space is potentially about 3Gb of mapped pages
all userspace memory is virtual swappable not actual physical ram
kernel space memory is the actual physical ram and is only used when necessary
in the kernel struct task-struct you get
struct mm_struct *mm;
which contains
unsigned long rss, total_vm, locked_vm;
every linux task gets a struct task_struct structure
total_vm is the total virtual size of the process it's code (execuable instructions) ,it's global and statically allocated data structures, and it's stack(local variables and function arguments and return arguments), and the heap( allocated memory using malloc() and free() and freinds in c or dynamically allocated in c++ with new and delete). the stack is cleaned automatically whenever the variables go out of scope but the stack still stays allocated to your process until it terminates. the heap can have the memory freed but that does not necessarily reduce the proccesses address space but it can if the memory subroutines do it that way. sometimes it just kind of grows and grows but as i said earlier not to wory because it is all virtual memory pages not real memory. failure to release memory properly however is memory "leaks" and can cause a process address space to grow without bounds till it fails from lack of memory. This is not generally a problem in Linux but sometimes software has small or large memory leaks. these can sometimes lead to data thrashing and performance problems as the kernel tries to keep needed info in active memory.
all of these memory structures follow GNU coding standard of "no arbitrary limits".
all process memory is returned when the process dies
ok i'm not really sure how this works but these memory structures are actually a part of the executable file itself
example:
Code:
(gary) ~ $ size /bin/bash
text data bss dec hex filename
484958 9996 25328 520282 7f05a /bin/bash
text is the executable code
data is non zero initialized daya
bss is zero initialized data
RSS is the actual real life physical memory that has been used to map to the virtual pages above
so RSS is the real program memory use number . This value sums the size of in-use code, data, stack, and allocated heap memory. not including memory shared between two or more processes. which is shared memory duhh.
Code:
(gary) ~ $ ps
PID TTY TIME CMD
1506 pts/0 00:00:00 bash
1721 pts/0 00:00:00 ps
(04:25am:05/26/05)
(gary) ~ $ grep "^Vm" /proc/1506/status
VmSize: 4872 kB
VmLck: 0 kB
VmRSS: 1716 kB
VmData: 580 kB
VmStk: 28 kB
VmExe: 476 kB
VmLib: 1628 kB
VmLib is shared libraries
you mention at the end x server memory usage and that is a unique case
x memory stats can be very confusing and or misleading
x memory shows an amalgamation or video card memory which is fixed and not you RAM at all plus i/o mapping pages to that video card RAM from the server side of x. Also image data from x clients reside on the server side of x looking like x memory usage, and the video driver for your video card often supplied by third party sources does some of the allocation and deallocation of memory that shows up in x server side memory and these drivers often have memory leaks that cause x memory usage to creap up over time but that does not really mean x is taking up more space in physical RAM i don't think.