All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nick Piggin <npiggin@suse.de>
To: Linux Memory Management <linux-mm@kvack.org>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>,
	Nick Piggin <npiggin@suse.de>, Andrew Morton <akpm@osdl.org>
Subject: [rfc][patch 0/5] 2.6.19-rc1: oom killer fixes
Date: Thu, 12 Oct 2006 16:09:34 +0200 (CEST)	[thread overview]
Message-ID: <20061012120102.29671.31163.sendpatchset@linux.site> (raw)

I've been prompted to take another look through the OOM killer because it
turns out it is killing tasks that have had their oom_adj set to -17 (which
is supposed to make them unkillable).

So there are a number of problems, firstly, the child and sibling thread
killing routines do not account for -17 children/siblings.

Secondly, most architecture specific pagefault handlers do a direct kill
of the current process if it takes a VM_FAULT_OOM. This is a pretty rare
thing to happen, because there isn't a lot of higher order allocations
happening, but it is not impossible. I think we can just call into the
OOM killer here, and return to userspace... but I'd like comments about
this.

Thanks,
Nick
--
SuSE Labs
 

WARNING: multiple messages have this Message-ID (diff)
From: Nick Piggin <npiggin@suse.de>
To: Linux Memory Management <linux-mm@kvack.org>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>,
	Nick Piggin <npiggin@suse.de>, Andrew Morton <akpm@osdl.org>
Subject: [rfc][patch 0/5] 2.6.19-rc1: oom killer fixes
Date: Thu, 12 Oct 2006 16:09:34 +0200 (CEST)	[thread overview]
Message-ID: <20061012120102.29671.31163.sendpatchset@linux.site> (raw)

I've been prompted to take another look through the OOM killer because it
turns out it is killing tasks that have had their oom_adj set to -17 (which
is supposed to make them unkillable).

So there are a number of problems, firstly, the child and sibling thread
killing routines do not account for -17 children/siblings.

Secondly, most architecture specific pagefault handlers do a direct kill
of the current process if it takes a VM_FAULT_OOM. This is a pretty rare
thing to happen, because there isn't a lot of higher order allocations
happening, but it is not impossible. I think we can just call into the
OOM killer here, and return to userspace... but I'd like comments about
this.

Thanks,
Nick
--
SuSE Labs
 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

             reply	other threads:[~2006-10-12 14:09 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-12 14:09 Nick Piggin [this message]
2006-10-12 14:09 ` [rfc][patch 0/5] 2.6.19-rc1: oom killer fixes Nick Piggin
2006-10-12 14:09 ` [patch 1/5] oom: don't kill unkillable children or siblings Nick Piggin
2006-10-12 14:09   ` Nick Piggin
2006-10-12 22:00   ` Andrew Morton
2006-10-12 22:00     ` Andrew Morton
2006-10-13  6:31     ` Nick Piggin
2006-10-13  6:31       ` Nick Piggin
2006-10-12 14:09 ` [patch 2/5] oom: cleanup messages Nick Piggin
2006-10-12 14:09   ` Nick Piggin
2006-10-12 14:10 ` [patch 3/5] oom: less memdie Nick Piggin
2006-10-12 14:10   ` Nick Piggin
2006-10-12 22:03   ` Andrew Morton
2006-10-12 22:03     ` Andrew Morton
2006-10-13  6:38     ` Nick Piggin
2006-10-13  6:38       ` Nick Piggin
2006-10-12 14:10 ` [patch 4/5] mm: incorrect VM_FAULT_OOM returns from drivers Nick Piggin
2006-10-12 14:10   ` Nick Piggin
2006-10-12 14:10 ` [patch 5/5] oom: invoke OOM killer from pagefault handler Nick Piggin
2006-10-12 14:10   ` Nick Piggin
2006-10-12 15:12   ` Kirill Korotaev
2006-10-12 15:12     ` Kirill Korotaev
2006-10-12 15:19     ` Nick Piggin
2006-10-12 15:19       ` Nick Piggin
2006-10-12 22:09       ` Andrew Morton
2006-10-12 22:09         ` Andrew Morton
2006-10-13  6:45         ` Nick Piggin
2006-10-13  6:45           ` Nick Piggin
2006-10-13  6:47           ` Nick Piggin
2006-10-13  6:47             ` Nick Piggin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20061012120102.29671.31163.sendpatchset@linux.site \
    --to=npiggin@suse.de \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.