Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.

Notices

Welcome to LinuxQuestions.org, a friendly and active Linux Community.

You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!

Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.

If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.

Having a problem logging in? Please visit this page to clear all LQ-related cookies.

Introduction to Linux - A Hands on Guide

This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.

Exactly what are they? How do they get allocated? When do they get freed? How much mem is freed by killing process <foo>?

(since you probably don't have time to explain this to me (you should be busy doing something else (like hacking at the kernel) if you know this stuff ), I'll gladly take pointers (which I then can point other people to) (and no, I don't program in Lisp (but I do like emacs for (among other things) its parens-matching)))

Btw, google is apparently not my friend (even though he might be your friend).

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:

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.

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.

so when I kill -9 firefox, I should expect at least(*) (in pseudo-code) mm_table[firefox].rss bytes to be freed, correct?

(*) shared libraries get freed when their refcount == 0, correct?
... so if FF is the only process that references libhtml-render-foo, killing FF should release (at least(*)) mm_table[firefox].rss + mm_table[lib-html-render-foo].rss

(**) okay, the kernel might do mark and sweep or stop and copy, but I like refcount: It's simple and intuitive. Also, can shared libs be circularly dependent?