Oh I'm sorry, if you were talking about copying of the address space information that can be avoided, that does not happen because it would've already been copied before exec() in the child gets a chance to execute.. the fork system call calls do_fork somewhere which calls copy_process which does this copying so it can't be avoided in any case. The book says copy-on-write itself has more overhead that is avoided with exec() in the child, but I'm trying to figure how. -Joel On Mon, Jan 11, 2010 at 12:18 AM, Manish Katiyar <mkatiyar@xxxxxxxxx> wrote: > On Mon, Jan 11, 2010 at 12:02 AM, Joel Fernandes <agnel.joel@xxxxxxxxx> wrote: >> Hi, >> The book Linux Kernel Development mentions a certain overhead which is >> reduced in linux because the child is made to run first after it is >> forked (instead of the parent) and if the child executes the exec >> system call. >> >> Quoting Pg 32 (2nd edition): >> "In do_fork() the child is woken up and run. Deliberately the kernel >> runs the child process first. In the common case of the child simply >> calling exec() immediately, this eliminates any copy-on-write overhead >> that would occur if the parent ran first and began writing to the >> address space" >> >> How does running exec() in child more efficient than having >> copy-on-write trigger in the parent? > > Hi, > > In order to create a new process (fork), you will copy the whole of > relevant info of address space from the parent. Now if the address > space is shared and parent runs first for any change it makes, it will > need to copy and then modify because it doesn't know if child needs it > or not. Since mostly after fork, if you do an exec it is guaranteed > that child will not need this address space and the whole of copy can > be avoided by making child to run first. (In simple terms you can take > decision early whether this address space is useful or not for child). > > Thanks - > Manish > > > >> >> Let me know if my question is clear, or if I should rephrase. >> >> Thanks! >> -Joel >> >> -- >> To unsubscribe from this list: send an email with >> "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx >> Please read the FAQ at http://kernelnewbies.org/FAQ >> >> > > > > -- > Thanks - > Manish > ================================== > [$\*.^ -- I miss being one of them > ================================== > -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
