Messages in this thread | | | Date | Tue, 21 Oct 2003 11:25:11 +0200 | From | Stephan von Krawczynski <> | Subject | Re: 2.4.23-pre VM regression? |
| |
On Mon, 20 Oct 2003 00:21:55 +0100 (BST) Ken Moffat <ken@kenmoffat.uklinux.net> wrote:
> On Thu, 16 Oct 2003, Andrea Arcangeli wrote: > > > > > sure. I think I already explained there are downsides in disabling the > > oom killer for desktops where the offender task is normally the biggest > > one too, but those downsides aren't something I care about given the > > cases it gets right w/o it (i.e. huge-shm-SGA/mlock/oomdeadlocks). the > > oom killer can do the wrong decision too sometime, and more > > systematically as well. > > > > Any chance of getting the oom killer back as an option ? On > 2.4.23-pre7 I made the mistake of trying to print a high-resolution > photo (300ppi, A4 size) using ghostscript while I was in X. I've only > got 128MB memory and about 256MB swap on that box, which obviously > wasn't enough (gs typically uses up to 300MB for a 200ppi A4 picture). > Only problem was that X got killed instead of gs, which left the box > unuseable. Last time I saw the oom killer in action it actually saved > me from having to reboot.
After having read numerous arcticles regarding oom killer/conditions/bugs/features I believe the lack of the oom killer is possibly the best scenario _without_ any user configuration. If you really want an oom killer it seems obvious that what you really want is a _configurable_ oom killer. The simple approach in configuration is handing it a list of processes it should _not_ kill. This means of course you need a user-space tool to mark processes as not oom-killable, possibly implemented as a kind of priority. Not set means "kill-at-will", set means top-priority gets killed as last. Did we already have this kind of proposal? :-) -- Regards, Stephan - 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/
| |