On Sun, 19 Mar 2000, Horst von Brand wrote:
>Jesse Pollard <pollard@cats-chateau.net> said:
>
>[...]
>
>> What waas offerred is not overcommit - a limited reserve allocation, not
>> the entire process.
>
>This is either-or. No "a bit overcommitted is OK", it _could_ lead to
>processes dying at random, which you aren't tolerating.
I'm not tolerating the lack of choice.
If I or management direct that I allocate quotas to users that exceed my
ram+swap-kernel(nonswap) then I expect to ocassionaly have OOM. If I need
the reliability then I will not do that.
My application right now is using Linux based PCs to control the operations
of the (second/third - it varis) largest unclassified computer center in the
DoD. I can't afford to have random crashes on these control systems.
>[...]
>
>> 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 infrastructure you are talking about just doesn't exist _at all_ (if it
>was extant, this discussion wouldn't be taking place at all), so your 0.5%
>is at best a crude guess. If you are counting the cost of Rik's patch,
>expanding this to a full-blown user quota system means:
It is a guess, but based on the performance variences between the systems
I am (partially) responsible for that do this.
>- Set up a data structure for keeping track of user's allowances, using up
> RAM
>- Adjust it each time said user does something. Note that most of the ideas
> for accounting shared resources that have been discussed here (divide the
> size of code segments among users, for instance) does need extra
> processing _for each current user_, and possibly extra infrastructure
> that just isn't there now
Not each time the user does something:
each fork/exec/mmap/sbrk.
>This doesn't sound like 0.5% of what the kernel does right now to me...
There may be some other locations memory has to be reserved, but already
there is excess? code for testing when OOM on every page fault. I am
recommending (at worst) add that amount of code to the fork/exec/mmap/sbrk
where memory is allocated. If this were rigidly enforced (and I'm not
saying completely disable overcommit) then testing on every page fault
would not be necessary.
Where overcommit is done the catastrophic OOM code is still needed on
every page fault.
-------------------------------------------------------------------------
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:29 EST