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
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?
> 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).
> 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.
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
for your on-disk data? With a mlock()ed stack, and being careful using it,
you're 100% safe. The problem is how to mlock() the stack.
>
> Peter
>
.TM.
--
____/ ____/ /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_____/ _____/ _/ Colombo@ESI.it
-
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