"Adam J. Richter" <[EMAIL PROTECTED]> writes:
[...]
> It turned out that the particular unix-like system on which
> these benchmarks were taken had a version of fork that did not run
> the child first. As it was explained to me then, most of the time,
> the child process from a fork will do just a few things and then do
> an exec(), releasing its copy-on-write references to the parent's
> pages, and that is the big win of copy-on-write for fork() in practice.
> This oversight was considered a big embarassment for the operating
> system in question, so I won't name it here.
>
> Guess why you're seeing this email. That's right. Linux-2.4.3's
> fork() does not run the child first.
Not always, if I understand correctly. Setting to always is putting
policy in kernel in a small way. If an app wants to fork and exec, it
should use *vfork* and exec, which is a performance win across many
OSs because the COW mappings don't even have to be set up, IIRC.
[...]
--
http://www.penguinpowered.com/~vii
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
