On Sun, 19 Mar 2000, Horst von Brand wrote:
>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.
What waas offerred is not overcommit - a limited reserve allocation, not
the entire process.
>
>[...]
>
>> > 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.
OOM should only happen if management policy is to allow it. Random crashes
that cannot be explained are forbidden.
>> > 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.
You can't do it by "risk". You have to do it by user quota.
>
>> 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).
These machines were swapping - I've used them. (2MB AT&T Release 1 and 2).
You could run a process up to the size of memory - kernel. If you wanted
to run two or more then you allocated n+1 * size of user memory in swap.
You NEVER had overcommit, and you never had random crashes.
>> 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.
The cost to current hardware is under .5 %. The actual code is mostly there
now, it just checks against the catastrophic condition instead of checking
agains a users quota.
The only difficulty is in deciding how to handle fork, and the ability
to identify fork/exec:
a. can fork reserve a small amount in case an exec follows
b. does fork have to reserve the entire amount everytime
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@cats-chateau.net
Any opinions expressed are solely my own.
-
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:27 EST