Messages in this thread | | | Date | Thu, 7 Dec 2006 23:22:07 +0000 | From | Alan <> | Subject | Re: additional oom-killer tuneable worth submitting? |
| |
> We add a new "oom_thresh" member to the task struct. > We introduce a new proc entry "/proc/<pid>/oomthresh" to control it. > > The "oom-thresh" value maps to the max expected memory consumption for > that process. As long as a process uses less memory than the specified > threshold, then it is immune to the oom-killer.
You've just introduced a deadlock. What happens if nobody is over that predicted memory and the kernel uses more resource ? > > On an embedded platform this allows the designer to engineer the system > and protect critical apps based on their expected memory consumption. > If one of those apps goes crazy and starts chewing additional memory > then it becomes vulnerable to the oom killer while the other apps remain > protected.
That is why we have no-overcommit support. Now there is an argument for a meaningful rlimit-as to go with it, and together I think they do what you really need.
Alan - 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/
| |