Messages in this thread |  | | | Date | Wed, 15 Mar 2000 15:39:41 +0000 (GMT) | | From | James Sutherland <> | | Subject | Re: Some questions about linux kernel. |
| |
On Wed, 15 Mar 2000, Paul Jakma wrote:
> On Tue, 14 Mar 2000, Rik van Riel wrote: > > > Indeed. There is always a way to fool any OOM killer. > > The only thing that could save us here are proper > > per-user resource limits, > > so isn't what should be concentrated on? Per user limits are a cleaner > way of fixing the problem.
They would AVOID the problem in a lot of cases - but not always. Yes, we should have per-user resource limits. Yes, they would help prevent malloc-bombs from being effective. No, they will not *prevent* OOM situations arising.
> i guess though it's a 2.5 thing. Rik, do you know of anyone > investigating per-user limits for 2.5? (a lot of linux users would > like to see it.. hint hint..) > > :) > > > but even then we'd still want > > an emergency OOM killer to rescue the system in situations > > where we hit the wall... > > > > OOM is a stopgap. Ideally we should be able to set ironclad policies so > that we never encounter OOM.
I doubt that could really be achieved. Dynamically reducing user rlimits to try to prevent them overloading the system would ALMOST achieve this - but what if a root process blows up? What if a couple of users all hit their resource limits at once? While individually they may not have high enough resource limits to OOM the box, a group of users would still be able to.
We can, of course, make OOM *almost* impossible. Per-user rlimits, plus a first-line userspace daemon (to prevent true OOM situations arising) will make this almost impossible - but never completely.
James.
- 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/
|  |