> Oh, and, <http://www.netbsd.org/Documentation/kernel/vfork.html>,
> just for the heck of it.
Somewhere this reads:
A good amount of effort was directed at making COW better in UVM,
but an address space-sharing vfork() still turns out to be a win.
It shaves several seconds off a build of libc on a 200MHz PPro.
I'm not sure how long a *BSD libc build takes -- but it would seem to
be your saving seconds on something that takes half an hour or more.
Hardly much of a saving -- and you could probably tune things
elsewhere to get an even greater increase in performance.
> No, not very good excuses. But it's pleasent to make something
> reasonably elegant -- and _quite_ traditional -- with so little
> effort.
It does actually give clues on how to cleanly implement it. We can
probably do it with 50 of so opcodes, in which case we may as well do
it... (hey, almost nobody uses the old stat calls, and they're still
there).
-cw
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/