0

When forking, the exact environment of the parent process gets copied. Is that space allocated in a random space in RAM or the parent and child processes are getting continuous RAM space (like array elements for example)?

  • Read your whole fork manpage, I bet you won't find that the child is created in such a continuous memory space. So, what then? – john Jan 21 '14 at 14:18
  • I don't think that this information should be in the man page either way. – ddmichael Jan 21 '14 at 14:55
  • Do you need an operating system that creates child processes next to its parents whenever possible? – john Jan 21 '14 at 15:06
  • No, I need to know if that is the general case out of curiosity. There must be an algorithm for that allocation. – ddmichael Jan 21 '14 at 15:40
  • I will try to (and you might do it too) look at the current Linux 3.13 particular fork implementation and try to give an example [obviously] not applicable to other kernels. Meanwhile let us hope a specific OS technician enlightens us about the general techniques. – john Jan 21 '14 at 16:08
1

If you download and extract it (linux-3.13) from kernel.org, you can see that in linux-3.13/kernel/fork.c there is a well documented bunch of functions. One, 'do_fork(...)' claims to do the actual fork. Here this function calls 'static struct task_struct *copy_process(...)', around line 1129. What you are looking for must be somewhere near.

OK here as I see, that function after checking selinux permissions calls 'dup_task_struct(...)', which calls 'alloc_task_struct_node(...)', 'alloc_thread_info_node(...)' and 'arch_dup_task_struct(...)'. Given the fact 'alloc_task_struct_node(...)' does "little thing more than calling kmem_cache_alloc_node(...)" and the fact that that function is declared in the file linux-3.13/mm/slab.c, which hints about memory management, and the fact that many kernel threads may be working against memory management responsibilities (creating and deleting structures continuously), I would bet Linux in particular does not by normal thing create process data structures one next to another, because of many threads doing the same generic allocations that fork uses.

If you open linux-3.13/mm/slub.c, it starts telling that is a slab memory allocator. An Internet Search Engine gives these results to that: wikipedia... and lwn.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.