Re: Avoiding OOM on overcommit...?

From: Peter T. Breuer (ptb@it.uc3m.es)
Date: Tue Mar 28 2000 - 09:34:34 EST


"A month of sundays ago Marco Colombo wrote:"
> On Tue, 28 Mar 2000, Peter T. Breuer wrote:
> > "A month of sundays ago Marco Colombo wrote:"
> > > On Tue, 28 Mar 2000, Peter T. Breuer wrote:
> > > > Overcommitment is fine. If you don't want it, reserve your own backing
> > > > swap space for your stack. That's all. Then you can't be murdered by
> > > > the kernel because the kernel will always be able to page you out.
> > >
> > > The problem does not occur when the kernel is trying to page *you* out.
> > > It occurs when the kernel is tring to page *another process* out.
> >
> > The kernel can't get swap to put that other process in? Then kill that
> > process. It's not our processes problem. We started up with reserved
>
> but it's your process that is page-faulting. And killing the other

No it's not. Some other process page faulted. It needs a new page
pulled in. The kernel has no memory, so it has to page someone out.
We have backing swap, so it CAN page us out. Only if NO process can
be paged out will someone have to die, and it won't be us, because we
can be swapped out.

> process you don't know if you're freeing any swap space. It's your
> process that have a page on swap. Mine doesn't. Why should be mine
> killed in a OOS situation?

I honestly don't understand what you are saying here. I am not killing
anything. So why should I know anything? Your process MAY be killed
in an OOM, since it can't be paged out and it's a question of who
should die, you or the process that wants to be paged in. Fine, I don't
care. It's one of you two anyway. Not me.

> > backing space in swap for our stack. It's the other processes lookout
> > if it didn't do the same. Presumably it didn't do it exactly because it
> > wanted to indicate taht it is a non-vital process that the kernel can
> > choose to murder if it needs the resource that it posseses (swap
> > occupation) for more important citizens. But we're OK. We can always
>
> since the kernel needs swap space to page it out, the process 'posseses'
> no swap (al least for that page).

You don't understand. That is what I am proposing that it possess.

> > be paged out without affecting anyone elses resource availability. We
> > have reserved swap just for that.
>
> you're just saying that since you showed concern about your swap usage,
> the kernel should treat you as priviledged. It's easier with a DONTKILLME
> flag.

No. Think again .. I think you don't understand the basic premise here:
that a process that has reserved swap to back its stack with can always
be safely swapped out, and hence need never die from OOM. Ergo any OTHER
process should be killed if OOM.

> Why don't you mlock() a piece of RAM (you're going to know if it's available
> at mlock() time), so you never page-fault, and use it just a as cache

This is a separate issue. I don't care about (heap) memory allocation. You
can always ensure you have memory at startup, or die. Malloc is not an
interesting or appropriate subject for the discussion. It's userlevel.

> for your on-disk data? With a mlock()ed stack, and being careful using it,

But you cannot have a mlock'ed stack.

> you're 100% safe. The problem is how to mlock() the stack.

And it's impossible.

Peter

-
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 : Fri Mar 31 2000 - 21:00:22 EST