Messages in this thread | | | Subject | Re: Memory hogs | Date | Sat, 17 Jul 1999 21:46:11 +0200 | From | Hermann Schichl <> |
| |
Claus Fischer wrote: > Werner Almesberger wrote: > : Hermann Schichl wrote: > : > I think it would be great if OOM handling would be > : > configurable (either kernel compile time or /proc interface) > : > : Better yet, have a device or proc file that becomes readable in this case. > : Then you can have a user-space demon to implement whatever policy you > : like. > : The demon can mlock its pages, so it should be reasonably safe from > : causing > : an OOM itself. Writing to that device/proc file could set the threshold > : for > : when OOM recovery is necessary. > : > : Reasonable policies may include enabling overflow swap space, SIGSTOP'ing > : all processes above a certain size/growth rate, paging the administrator, > : and opening a shell on the system console. > : > : - Werner > > > I'm not against user-space solutions as a supplementary measure. > I'm however totally against saying: "We'll find a userspace solution, > so it's OK for the kernel not to do anything intelligent." > > Not for Linux. > > This is the OS that I have carefully chosen for my desktop machine; > it hasn't been imposed on me by my managers, and I want it to shine > even where others spread darkness. > Same here. Though, I somewhat imposed it on the managers. > > If you have a good userspace solution, this is not the discussion > for you. Go ahead and implement it and you're saved. Stop reading. > You don't care for the kernel OOM situation any more. [1] > This is not quite correct since it needs a proper kernel interface to construct a useful user space solution. Werner, IMHO, correctly pointed out that the FANCY solution stuff and the configurable parts should go to user space. The kernel itself should provide a reasonable default action which is stateless, simple, fast and small. I think we all agree that the kernel has to take proper measures to keep the most important processes running. > > But if you use Linux in the way computers are used by real men: to > further the progress of mankind by performing the most complicated > and memory-intensive simulations, they you'll certainly agree that > the Linux kernel should do better than falling in with the crowd > of "well you can't just do that to our operating system" designs. > That is the point. IF you are doing the most complicated and memory-intensive simulations then you want to GUARANTEE that this one does not die after five days of computing time. > > The kernel should not let the machine die and become unusable. It has > to guarantee the bare survival, which includes: integrity of init, > rlogind, etc. On my desktop box, it had better let X survive as well, > Yes, and my simulation if ever possible. And if the simulation is the problem, I probably would prefer to stop the process, decide to add some more swap space if I have some free hard disk space and continue the process. > > if it wants to be regarded a strategic ally (remember, the goal is > saving mankind :--) >
To summarize my opinion: We need proper kernel handling of OOM situations it should be simple, stateless, and failsafe. In addition we should have a nice interface (device, proc, ...) which makes it possible to construct a user space solution of NEAR OOM situations which is configurable (fancy and shining :) if necessary) to make it suitable for (almost) all needs out there.
Hermann
- 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/
| |