> About the "use resource limits!". Yes, this is one solution. The
> *expensive* solution (admin time, worse resource utilization, etc).
traditional user limits have worse resource utilisation? think what
kind of utilisation a guaranteed allocation system would have. instead
of 128MB, you'd need maybe a GB of RAM and many many GB of swap for
most systems.
some hopefully non-ranting points:
- setting up limits on a RH system takes 1 minute by editing
/etc/security/limits.conf.
- Rik's current oom killer may not do a good job now, but it's
impossible for it to do a /perfect/ job without implementing
kernel/esp.c.
- with limits set you will have:
- /possible/ underutilisation on some workloads.
- chance of hitting Rik's OOM killer reduced to almost nothing.
no matter how good or bad Rik's killer is, i'd much rather set limits
and just about /never/ have it invoked.
more beancounting will make limits more useful (eg global?) and maybe
dists can start setting up some kind of limits by default at install
time based on the RAM installed and whether user selected
server/workstation/etc.. install.
Then hopefully we can be a little less concerned about how close Rik
gets to the impossible task of implementing esp.c.
> Szaka
--paulj
-
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/