Messages in this thread |  | | | Date | Tue, 11 Jan 2005 16:46:01 -0400 | | From | Ilias Biris <> | | Subject | Re: User space out of memory approach |
| |
well looking into Alan's email again I think I answered thinking on the wrong side :-) that the suggestion was to switch off OOM altogether and be done with all the discussion... tsk tsk tsk too defensive and hasty I guess :-)
Thinking it in another way alan's email could have the dimension of switching off overcommitment (and thus OOM) whilst in the user-space ranking stage to avoid reentrancy and invocation of oom again and again before killing something. It also solves the issue of using timed/counted resources which is plain ugly and evil. It would though be necessary to switch OOM back on when the OOMK has finally done the kill.
Did I get it right this time Alan?
On Tue, 11 Jan 2005 15:16:04 -0400, Ilias Biris <xyz.biris@gmail.com> wrote: > Hi > > where I come from we say (jokingly of course) 'got a headache? chop > your own head ... end of problem'. > > Though your system is not guaranteed to become more stable. When you > forbid overcommitting memory, all you do is make failure occur for ALL > processes at a different time. A process is happily doing something > useful when all of a sudden its fork may die due to 'out of memory' > ... Moreover shutting down overcommit will do that for all processes, > not just the one culprit that could be chopped off by oom... > > Maybe it is just me but I think with overcommiting a system works more > reliably :-) > > On Tue, 11 Jan 2005 16:32:23 +0000, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote: > > On Maw, 2005-01-11 at 08:44, Thomas Gleixner wrote: > > > I consider the invocation of out_of_memory in the first place. This is > > > the real root of the problems. The ranking is a different playground. > > > Your solution does not solve > > > - invocation madness > > > - reentrancy protection > > > - the ugly mess of timers, counters... in out_of_memory, which aren't > > > neccecary at all > > > > > > This must be solved first in a proper way, before we talk about ranking. > > > > echo "2" >/proc/sys/vm/overcommit_memory > > > > End of problem (except for extreme cases) and with current 2.6.10-bk > > (and -ac because I pulled the patch back into -ac) also for most extreme > > cases as Andries pre-reserves the stack address spaces. > > > > - > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > the body of a message to majordomo@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > Please read the FAQ at http://www.tux.org/lkml/ > > > > > -- > Ilias Biris >
-- Ilias Biris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |