Olaf Weber <olaf@infovore.xs4all.nl> said:
> Horst von Brand writes:
> > Olaf Weber <olaf@infovore.xs4all.nl> said:
> > [...]
> > Many architectures don't know of read-only data, so you must
> > consider them writeable anyway.
> If you can implement copy on write, you can implement abort on write.
> And if you cannot implement copy on write, how do you implement
> overcommitment?
COW is then implemented by marking the page as non-available, when accesed
you fault and look at what is going on.
[...]
> For fork/exec, you might want to have a "special" fork which is safer
> than vfork but doesn't imply the need to reserve a copy of all the
> writable data. Or, as someone proposed, you fudge fork to allow a
> limited form of overcommit until the next system call.
"Limited form of overcommit" is overcommit, a no-no for non-overcommiting
systems. No dice.
[...]
> > Marking "de-facto read only by the process" is error-prono, and will
> > be done wrong enough of the time it will be taken back. OOM is rare,
> > program chrashing because "I thought read-only but overlooked..."
> > will be frequent.
> It would be the program itself that marks pages read-only, so if these
> pages are subsequently written to it either means they shouldn't have
> been read-only (and the extra memory was needed after all), or there
> was a hidden bug in program.
Exactly! Programs which get it wrong break right and left, "But it worked
fine before!". Go back, as that didn't cause problems in 99.98% of cases,
and where it did, there were much more serious problems (OOM) anyway.
> > Next time go ask your bank if they have the cash handy for the case that
> > everybody decides to close their accounts the same day.
> Actually banking is not a bad analogy: just remember that they are
> subject to strict rules w.r.t. to the extent to which their cash
> reserves may be overcommitted, and are also obliged to have the assets
> to cover _all_ commitments. Banks also differentiate between good and
> bad risks.
> In terms of risk it makes a real difference if you overcommitted 100MB
> of de-facto read-only COW memory, or 10MB of de-facto read-write
> memory: the latter commitment is the one that kills.
Something like that should be put into the kernel. Problem is, how do you
diferentiate sanely between good and bad risks here? Basic problem is that
you get _potentially_ writable COW memory, and no way to know if it will be
written or not, or even just discarded the next few instructions ahead.
> In general, my point is just that some advocates of overcommitment
> exaggerate the amount of extra VM that a non-overcommitting system
> would require. An OOM situation is bad on both systems, though I
> believe programs have a better chance of coping with it on a system
> that doesn't overcommit.
Try it once, you'll be very surprised. Some of the first machines I laid my
hands on had no COW, so no memory overcommit. They had roughly the same
amount of RAM + swap as later overcommiting machines I've got, which could
stand much higher loads (and needed it badly, as processes became larger
and CPUs faster, and thus more simultaneous users).
> If you have the infrastructure necessary to prevent overcommitment,
> you are also in a position to allow it to a limited extent, or in
> certain special cases. Without that infrastructure, no-one has a
> choice.
The problem here is the cost (of the infrastructure, and its impact of
performance) vs. what it buys you. My argument is that it buys very little
(if anything) for a sizeable cost.
-- Horst von Brand vonbrand@sleipnir.valparaiso.cl Casilla 9G, Viņa del Mar, Chile +56 32 672616- 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/
This archive was generated by hypermail 2b29 : Thu Mar 23 2000 - 21:00:26 EST