Newsgroups: comp.unix.aix
Path: utzoo!utgpu!dennis
From: dennis@gpu.utcs.utoronto.ca (Dennis Ferguson)
Subject: Re: vfork() (was Re: RS6000 questions/comments)
Message-ID: <1991Jun30.190147.19513@gpu.utcs.utoronto.ca>
Organization: none at all
References: <1991Jun27.221208.14845@kithrup.COM> <8903@awdprime.UUCP> <351@devnull.mpd.tandem.com> <889@rufus.UUCP> <19439@rpp386.cactus.org>
Distribution: usa
Date: Sun, 30 Jun 1991 19:01:47 GMT

In article <19439@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes:
>In article <889@rufus.UUCP> drake@drake.almaden.ibm.com writes:
>>The RISC System/6000's fork() implementation is quite efficient, making
>>"vfork" unnecessary for performance reasons.  Nonetheless, vfork() *is*
>
>I don't know what you call "particularly efficient", but I have measured
>fork/exit performance and AIX v3 is worse than SVR1 on a 12MHz 68000 that
>I tested in 1986.  As I recall a S/6000 Model 530 produced about 8 or 10
>fork/exits per second, compared to about 45 per second on an Mpulse/XL
>that I was testing for my employer in 1986 (Pinnacle Systems, Inc.,
>Garland TX)

I'm not sure about "8 or 10 fork/exits per second", but I do know that
inverted page tables and segments make a copy-on-write fork() quite
difficult and expensive to implement.  For the RT it was easy to write
a program which ran under Mach (full copy-on-write fork()) at about 5%
of the speed that it would under AOS (traditional copy-all-data fork()).
Page tables are global, rather than per-process, on the RT and the
RS/6000, and memory sharing is done by segments rather than pages.  This
makes it nearly impossible to avoid rewriting the (global) page tables
during process switches if you are doing copy-on-write forks, and this
can be very expensive particularly if both the parent and child continue
running after the fork().  This, by the way, is a reason why one might
wish to let the child run first after a fork().  You can save yourself
a lot of grief if the child has the decency to exit() or execve() quickly
after the fork(), this avoiding the expensive process switches between
child and parent altogether.

I have no idea what AIX V3 actually does about this.  There are
alternatives to pure copy-on-write (e.g. copy-on-access) which can save
some of the cost during process switches at the expense of other
tradeoffs.  I do note, however, that while I agree that vfork() is
a hack, the traditional fork()/vfork() combination was indeed a good
match for what you can do easily on a machine with inverted page tables
and segments: copy all of the data segment or copy none of it.  Whatever
IBM has done to make their fork() "efficient", I doubt that it is all
that "efficient" compared to machines which do copy-on-write with more
conventional memory management.  Certainly the tradeoffs would be
different.

Dennis Ferguson
University of Toronto