"Peter T. Breuer" <ptb@it.uc3m.es>
> "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
The real problem isn't whether or not stack can be locked. NO process should
be killed as long as that process (and its' process group) is under the
users memory quota. It doesn't matter whether it is stack, heap, or text.
There is no quota control now, but there should be.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil
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 : Fri Mar 31 2000 - 21:00:22 EST