lkml.org 
[lkml]   [2000]   [Mar]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Avoiding OOM on overcommit...?
Date
On Wed, 22 Mar 2000 07:33:12 -0600 (CST), you wrote:
>James Sutherland <jas88@cam.ac.uk>
(snip)
>> Yours, if you don't have enough resources available to you to run it.
>> Otherwise, both run fine.
>
>BUT "when I use up the resources given to me" - If the resources weren't
>available, why did the system give them to me?

It didn't.

>> >Who gets killed - your process or mine?
>> Yours, because there aren't enough resources to run it.
>
>The system told me there were enough resources.

You asked it if there was 128Mb of VM free; there was. Half an hour
later, you try to use 128Mb of VM and fail. There is a rather simpler
explanation than the nasty kernel having lied to you...

>> >Which is the correct one?
>> Yours, as above.
>As determined by what?

System policy.

>> >How do you know it is the correct one?
>> Because it would put you above the limit available to you.
>
>But the system told me the resources were available. And what limit?
>The kernel doesn't support resource quotas.

I'm pretending for the moment it does; if we can pretend it doesn't
have overcommit, we can pretend it does have per-user rlimits, too.
We have already agreed that it SHOULD have this feature, and
eventually, it will. If you want it so badly, pay for it.

>> >If it happens again, are the answers the same?
>> Yes.
>
>BUGGGY. The system gave the resource to me. See above. What distinguishes
>my job from yours?

I loaded a program when there WERE enough resources to support it. You
loaded the same program when there were not. I got the resources I was
allowed, you got the resources available to you.


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.127 / U:0.088 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site