Lennart Sorensen wrote: > On Fri, Apr 09, 2010 at 03:21:47PM +0800, Ben Kloosterman wrote: > > On x86_64 segment registers ( in long mode ) are all 0 based ( except for FS > > and GS) > > > > Also im not sure what the above gets you. Forks are not common ( in terms of > > instructions) so im not sure perf even matters. > > Normally an app loads from the disk and then it creates a sub proc via a > > fork , when comparing to a disk a few micro seconds to copy the memory is > > not a big deal. > > fork is not common in a daemon. Some other applications may do lots > of forks. Depends what the application is. There is no such thing as > 'normal application'. Just remember lots of things call system() to > do things.
Fortunately system() can use clone() or vfork(), and daemon can use clone() too :-) We really don't need fork() for much. > Waste of time, memory and cpu cycles. Also patching might be harder > since at load time there is no data containing pointers to anything. > It is a well known state. Once something has been running, you have no > idea what might contain pointers anymore. Sure you can fix the function > pointers and such, but you can't fix the stack and other data that may > contain pointers to things. Doing it the Minix way, by copying mappings around in the kernel when context switching, would be much easier than requiring complex toolchain support and restricting the languages to special environments. Since you don't need to copy !PROT_WRITE mappings, including main program code and shared library code, it isn't always much data to copy either. Code is often larger than data for the sort of thing which run on small no-MMU systems, but x86 no-MMU with gigs of RAM might be different. It is quite feasible to implement fork() in the kernel, but I don't expect anyone to volunteer the kernel patch any time soon. Note that this method does not work too well with SMP: parent and child cannot run concurrently until they have no overlapping private mappings (generally meaning exec). I think we are much better off pushing apps to use clone and vfork where appropriate. Often there isn't a lot to do (although I've seen plenty of cases with "#define fork vfork" where the code isn't vfork-safe). Using fork+exec to spawn a child process the Minix way temporarily requires double the data memory, aside from the data copying time. fork would be useful occasionally, to make some program work that would be a lot of work to change, but it might also encourage excessive use of fork on no-MMU systems where it should be discouraged. -- Jamie _______________________________________________ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
