Looking over the last few weeks of postings, there are just WAY to many
conflicting ways that people want the OOM to work.. Although an
incredible amount of good work has gone into this, people are definetely
not happy about the benifits of OOM ... About 10 different approaches
are being made to change the rule based systems pertaining to WHEN the
OOM will fire, but in the end, still not everyone will be happy..
The old way of having a machien crash when you asked too much of it
seemed acceptable.. People then either chose to run the mem hog, and
upgrade their boxes, or they stopped running the memhog.
Maybe its time to hear from on high whether OOM capability outweighs the
problems that seem to be associated with it?
Either that or we should be able to allow the end user/and the distros
to decide what gets killed by OOM.
Some people might like to just say to heck with it, and not let anything
get killed, while others may just want to protect certain things..
Speaking completely where I don't belong, and don't know enough about..
Just a thought, can we come up with a new form of execute bit that would
define whether OOM should affect the process? Then the app can be made
to be killable if not as root etc... As well as being applied simply at
a per application basis, because we KNOW that not all applications will
ever be completely system friendly..
There will always be useful programs that might not fit into a OOM model
well.
Linus has been notably quite of late about this issue, given the amount
of contention on this issue..
On 29 Mar 2001 07:41:44 -0800, David Konerding wrote:
> Now, if you're going to implement OOM, when it is absolutely necessary, at the very
> least, move the policy implementation out of the kernel. One of the general
> philosophies of Linux has been to move policy out of the kernel. In this case, you'd
> just have a root owned process with locked pages that can't be pre-empted, which
> implemented the policy. You'll never come up with an OOM policy that will fit
> everybody's needs unless it can be tuned for particular system's usage, and it's
> going to be far easier to come up with that policy if it's not in the kernel.
-- "Catch the Magic of Linux..." -------------------------------------------------------- Michael Peddemors - Senior Consultant LinuxAdministration - Internet Services NetworkServices - Programming - Security WizardInternet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com -------------------------------------------------------- (604)589-0037 Beautiful British Columbia, Canada- 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/
This archive was generated by hypermail 2b29 : Sat Mar 31 2001 - 21:00:22 EST