*I* wouldn't assume that, ever. Copy-on-write vfork() is fork() with a
different name. _I'm not saying that is a bad thing._ It's just not
vfork(). Assuming vfork() is not just an alias for fork() is not wise.
Assuming vfork() *is* just an alias for fork() is just plain silly.
> Assume also that overcommitting is turned off.
_The main point I've been trying to make_ is that having *both* overcommit
and no-overcommit behaviors available *simultaneously* is a GOOD THING.
The second point is that having vfork() behave differently than fork() is
*one* way to have this GOOD THING.
The third point is that this is existing practice for several UNIXen already.
> Given these two assumptions, I believe it is disastrous to allow 'vfork' to
> succeed if there aren't enough swap pages to back every single copy-on-write
> page.
So, with the second assumption "that overcommiting is turned off", it would
be disastrous if overcommiting were turned on. I never would have thought
of that. :-)
> If overcommitting has been turned off, that should be that.,
If the intention is to prevent overcommiting, that should be honored. If
the intention is to allow overcommiting, that also should be honored.
There are good, real world examples of why having both behaviors available
simultaneously is a GOOD THING.
Since you have a firm grasp of why overcommiting can be bad, I'll give you
a real world example of why it can be good. In microelectronics, database
sizes -- in RAM -- frequently exceed 1GB. Sometimes, they even exceed 4GB.
(I've personally had to build special versions of Perl for processing these
monsters.) Because of the expense, hosts processing these databases are
only rarely configured with _more than twice the amount of RAM_ it takes to
process one of of these large databases at a time. Programs processing
this data *frequently* run for more than 10 hours. Sometimes they run for
several *days*. If this process starts paging because of lack of RAM, it
can increase the run time by factors of 10. At the completion of
processing, these programs sometimes call external programs. Frequently,
external programs are a required part of printing the result. Sometimes,
external programs are a required part of saving the result to disk in a
useful format. Saving the result to disk in a useful format is usually
_the entire purpose_ of running the program in the first place.
popen(), ENOMEM, bummer! (Similar applies to Perl in additional contexts.)
Now imagine yourself as a Developer or Sys Admin, explaining to a room full
of engineers and project managers why a machine that costs more money than
you make in a year needs twice the huge amount of RAM it already has when
they can log in, run "top", and observe that the total amount of RAM used
never exceeds 90%, *hundreds* of MB RAM free, right up to the very end of
processing. You can bet some of the engineers already know the external
filter program never uses more than 12MB RAM, ever. Alternately, imagine
explaining why you need to allocate 8GB of swap on a particularly fast and
expensive disk -- when it will *never* be used -- by design. Imagine
explaining why the project schedule just slipped the better part of a week.
Punchline: Rather than sitting idle most of the time, this same expensive
machine also hosts applications for which overcommiting would be
disastrous.
I've experienced this environment as described at three different
companies. (Specific numbers vary.) Fortunately, I have been able to
avoid the explanation scenario because of learning to properly use (and
avoid) vfork() on commercial UNIXen -- where it makes a difference.
While plotting world domination:-), please consider the many engineers who
work in environments like these who would *love* to see Linux play a larger
role.
Hope this helps,
Chuck
-
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/