Reducing the *number* of system calls is not the solution. The problem is that vfork and exec don't know that they are called in a sequence. This and the surrounding system calls work all independent from each but touch the same or related data pools. IMO there is a lot room for optimisations, such as less locking, less touched pages and kernel having the authority and *knowledge* in which *order* things are done the way best, and *consolidation* if a single call - this is posix_spawn - passes all data in one step.
I agree that Solaris would have to main tain a code path for vfork,exec and an other for posix_spawn, but IMO it is worth the work because modern shells are moving to use posix_spawn, ksh93 was the first and the rest, like bash and tcsh, are following now. Shell script performance is still very important - if I understand the comments of Sun sustaining it is missing critical - and any optimisation is welcome and important for business. ksh93 tackled part of the problem by introducing many POSIX utilities as shell built ins, but not all utilities can or should be provided as built ins and not all scripts use ksh. I doubt that there is some thing to tune in the VM system to improve vfork,exec performance: vfork looks straightforward and the problems with exec - such as the number of cross calls to other cpus representing a bottleneck for scalability on machines with many cpus - require a total new architecture of the way how Solaris manages the virtual memory. This is there fore unrealistic and not going to happen any time soon, if any time. Olga 2010/7/14 Bart Smaalders <bart.smaald...@oracle.com>: > On 07/13/10 19:13, ольга крыжановская wrote: >> >> I am the wrong person to do such an investigation - I am no Solaris >> kernel internals expert. > >>> ... >>> >>> What does DTrace tell you about where the time is being spent? >>> Instead of asserting where the problem is in email, how about >>> doing some investigation? >>> >>> - Bart > > In that case, your suggestion that we should improve process fork > rates is noted, while suggestions to reduce the number of system > calls as the best place to start is given less weight :-). > > Seriously, re-implementing spawn as a system call is a lot of work, > and would result in the need to maintain dual code paths (spawn & fork/exec) > that would need the exact same behavior in terms of > inheritance of characteristics, etc. This is a significant on-going > maintenance burden, and the kernel folks are generally loathe to do > so unless there were advantages, not just better shell script > performance. > > There are other, more generically useful performance improvements > being made in the VM system that will help this; given our limited > resources we'd rather focus on projects that have good paybacks in > multiple areas. > > - Bart > > > -- > Bart Smaalders Solaris Kernel Performance > bart.smaald...@oracle.com http://blogs.sun.com/barts > "You will contribute more with mercurial than with thunderbird." > -- , _ _ , { \/`o;====- Olga Kryzhanovska -====;o`\/ } .----'-/`-/ olga.kryzhanov...@gmail.com \-`\-'----. `'-..-| / http://twitter.com/fleyta \ |-..-'` /\/\ Solaris/BSD//C/C++ programmer /\/\ `--` `--` _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
