hello Thomas... > Maybe because the child is likely to do an exec() syscall soon after > the fork(). So, we'd better run the child, let him call exec() before > doing any COW. If we run the parent before, he will follow its > execution, eventually writing to pages, doing unnecessary COWs > because the child is going to exec() shortly after. hmmm....parent runs first....modify something...COW is triggered (because the physical memory area is still considered as shared). Plus, the "new kid on the block" suddenly do exec*(), dumping all inside its address space...loading new ELF binary. OK, in short, if we don't do "child run first"....worst nightmare will happen..COW (perhaps lots of them) followed by complete process address space thrashing by the "kid". I can imagine the cost... If we do "child runs first", then in "exec" scenario: the kid exec()...loading new binary..therefore thrashing the whole address space . this doesn't cost too much since no physical memory is allocated yet (except for task_struct and page tables). OK, this is the part which needs confirmation..once the child does exec*(), the parent's address space is no longer considered in COW mode? So, any write toward its own memory areas (writable area of course, such as heap) won't trigger new page allocation and old page invalidation? again, CMIIW... > This may be a reason for the "child should run first after fork()" > rule. This is just a personal speculation, I'm not a kernel expert. Same here :) That's why we are all here, right? because we are not expert :) if we are expert, this list will be known as "kernelexpert@xxxxxxxxxxxx" :)) he he he regards Mulyadi -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
