lkml.org 
[lkml]   [2000]   [Mar]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Avoiding OOM on overcommit...?
Date
On Tue, 21 Mar 2000 13:05:15 -0600 (CST), you wrote:
>James Sutherland <jas88@cam.ac.uk>:
>> On Mon, 20 Mar 2000 22:02:33 -0600, you wrote:
>> >On Mon, 20 Mar 2000, David Whysong wrote:
>> >>On Mon, 20 Mar 2000, Jesse Pollard wrote:
>> >>
>> >>>Without overcommit:
>> >>> You can support 100 simultaneous connections, with full saturation of
>> >>> each server, with no failures.
>> >>>
>> >>> Result: happy customers, happy management, maybe even a raise.
>> >>>
>> >>>If you overcommit:
>> >>> You might support 100 simultaneous connections, but not full saturation
>> >>> of each server, without aborting some connections or crashing the
>> >>> server/system.
>> >>>
>> >>> Result: some unhappy customers, not so happy management, difficulty
>> >>> in identifying problems, and definitely no raise.
>> >>>
>> >>>So you used 2G byte of swap - I know where you can by 18GB of swap for about
>> >>>$300 US...
>> >>
>> >>That's very misleading. In fact if you give the overcommitted system the
>> >>same amount of VM, it will work just fine.
>> >>
>> >>In other words, turning off overcommit isn't what saves you. You added
>> >>more memory!
>> >
>> >I guaranteed that the memory allocated could be used. I didn't just add
>> >more memory. Just adding more memory will still allow the system to fail,
>> >it may take longer, it may not happen as often. But it can still happen.
>>
>> In EVERY case where your non-overcommit system operates correctly, my
>> overcommitted machine does too.
>
>True.
>
>> Under heavier load, there is a point where my system continues to
>> operate correctly but yours fails with OOM errors.
>
>NOPE. none. Under heavier load the resource quotas prevent a process from
>exceeding the permitted limit. the system does not fail.

The user quotas on my system do the same.

>> Finally, we reach a heavy overload situation, where both systems fail
>> with OOM errors.
>
>NOPE again. the only time both will fail is if both are overcommitted.

No, yours will fail because it is out of memory too.

>> Explain why you believe causing the second situation to fail
>> unnecessarily is an improvement.
>
>It is not unnecessairy - it has exceeded the allowed limits for that user.
>Management has stated that that user is not allowed to interfere with other
>users.

That's a quota. I'm talking about overcommit, not the quota settings.

>> >The quotas prevent someone from exceeding what is really alloted to the
>> >job. If the job exceeds that quota then something is wrong, it gives a
>> >control point, AND it prevents the "something wrong" from affecting the
>> >rest of the system.
>>
>> Yes, we KNOW you want user resource quotas. You can't have them yet,
>> so stop talking about them - they are irrelevant here.
>
>Why "you can't have them yet"? Does that mean it IS planed to put resource
>quotas in? This is the first I've ever heard that it was planned.

It is, and has been for a long time, AFAICS. It just hasn't been
written yet, because there isn't enough demand.

>And I don't think they are irrelevant. If this is not the location to
>discuss kernel features, what is?

It is. However, there is nothing to discuss - I KNOW we need user
quotas. Continuing explaining WHY we need them achieves nothing.
Either write the code yourself, pay someone else to do so, or wait for
someone else to do so of their own accord. Don't continue justifying
the need for them - we've already accepted that.


James.

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.039 / U:2.132 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site