Hello... I try to add some explanations. Beware that devil is still in the detail so RTFC (RTF Code) is still the best... > The child gets a COW copy of everything that is writable (but I'm not > sure what happens with shared memory in the parent or the stack - > though I think the stack is COW'd just the same). It get's > non-writeable stuff shared in (ie the .text section and the .rodata > section). >From what I read, all the VMAs of the forking process is marked as read only and COW is applied to all these regions. Since the program codes is only read and then executed, it will stay same through all forked processes (descedants). The only occassion where the code section is dumped is when the child does exec() (and the gang, like execve() ) take a note, that what "copy" really means is actually "setting the page table to point on the existing physical page". So, the child is actually given new process address and whole new page tables, but these page tables is pointing on the COW'ed physical pages of the parents. You can consider it like two different and separated people going to visit a museum. One is told to walk 600m to south direction, the other is told to walk 700 to east direction. Both directions are correct and pointing to same museum. But each person has different "mapping", and this mapping are page tables :) > I believe, from Linux's PoV, that a thread doesn't have a parent. All > threads in a process are equal. A thread's stack is just an area of Are you sure about this Tristan? IMHO every process has a parent, even it is a thread created on NPTL environment. Perhaps you got this impression since each thread has same pid? > > 3) A thread stack is created INSIDE the address space of the > > parents stack. For example, if a parent's break_value is at > > 0x60000000 and it's stack pointer is at 0x80000000, then if we > > create another thread, it's stack will be somewhere between the > > break_value and stack pointer (i.e., end of parent's stack space) > > of the parent? > > If you create a thread it will be somewhere that the process could > mmap anonymous pages, that's really all the detail required. BTW, the Every process/thread has distinct stack area, so there won't be any overlapping stack area. > > 4) During a context/process switch, the stack pointer is popped > > from the registers. Where does it go (stored on the hard disk?), > > and which registers are popped from the stack? What about all the > > OTHER values in the address space? You mean, where it is saved so later it can restored? If this is what you mean, read about "thread_struct" structure inside the task_struct. That's where the Stack pointer of current running process is saved during context switch I don't understand about your question "which registers are popped from stack?" If what you mean, is there something popped from (kernel?) stack, then the answer no...nothing is popped from kernel stack. Other value in the address space? you mean, the data saved on the related address space? Well, no worries, it is still there (on memory). The new running process can non touch most of them, since it is given whole new set of virtual addresses, which is (mostly) mapped to different physical pages. The exception is process created by CLONE_VM > > For example, I am executing process-A and it has a timeslice on the > > CPU. After it's expired, process-B takes over. Process A must be > > having a lot of variables the values of which must be stored in the > > address space of process-A. Now, if we store only the stack > > pointers and a few other register values, where do we get the whole > > lot of variable values from when we reinstate process-A into the > > CPU? For example, how does the CPU know about the "text" segment > > or let's say the data segment? read the mm_struct and pay attention on its VMAs, this is the place where the kernel know where is the virtual address of code segment, data and so on. The real related physical address is pointed by the help of page directory and page tables. > > 5) In linux VM, all processes think they have the whole range of > > physical memory at their disposal. Can two processes (A and B) have > > a mapping to the "same" physical address? They are not sharing > > memory, btw. Or is it that if a process is not sharing memory, > > every one of it's pages will have to have a different address in > > the physical space (different from all the page frames of ALL other > > processes).? In short, yes...two or more processes can share same physical pages. The possibilities are: 1. Those processes use the same shared libraries 2. on COW scenario 3. Not sure about this, but logically it should be. Shared memory area which is attached by two of more processes (the one created with shmget() ). Perhaps there are other possibilities....but I can't remember them all. Other people might add these.... regards Mulyadi -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
