On 14/07/2010 19:24, johan...@opensolaris.org wrote:
On Wed, Jul 14, 2010 at 01:12:37PM -0500, Nicolas Williams wrote:
On Wed, Jul 14, 2010 at 11:06:38AM -0700, johan...@opensolaris.org wrote:
On Tue, Jul 13, 2010 at 06:41:32PM -0500, Nicolas Williams wrote:
As to your question, posix_spawn(2) wouldn't fork at all under the
covers: as a syscall it'd not have to. It'd create a new process as a
child of the parent, but it'd not use the parent's address space at all.
There'd still be some amount of locking to copy the file descriptor
table and so on, of course, but nothing quite like the copying or
borrowing of the parent's address space (almost certainly the most
expensive part of fork(2)/ vfork(2)).
I'd like to see data for this assertion too. The code that's executed
for vfork performs very few address space manipulations while borrowing
the parent's address space. All it does today is clear and restore
watched pages. Most processes don't have watchpoints on their pages.
"Borrowing the parent's address space" means stopping all of the
parent's threads, at least for vfork() because that's what the
documented semantics of it are. I've explained this elsewhere in this
thread. I'm sorry you thought that I meant that vfork() does expensive
address space manipulations.
So back to Bart's point about the maintenance burden of two separate but
nearly identical code paths. Without any data, this discussion is very
silly.
It is now eight years since libMicro started to hightlight some of the
major gaps between Solaris and Linux (of which fork/exec was a
significant gap). In response someone at Sun even coined the aphorism
"If Linux is faster, it's a Solaris bug!" (mea culpa).
If you want data, it would be very trivial to compare fork, fork/exec
and posix_spawn performance on Solaris and Linux on current hard
hardware. I'd expect that you'd find Linux is still considerably faster
than Solaris in the area of process creation (sometimes because Solaris
is safer, more scalable, contains lanolin, etc and sometimes because it
just could do with some TLC).
I don't see that the two code paths would necessarily be that different.
Actually, I'd hope that a lot of the code path would be the same (isn't
that one of the import reasons we use functions in C?). I'd also expect
that fork/exec performance would benefit from such an exercise.
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org
