oom: select_bad_process: check PF_KTHREAD instead of !mm to skip kthreads
in [Kernel]
|
Prev: [PATCH v2] printk: fix delayed messages from CPU hotplug events
Next: Article in Phoronix about loss of performance in 2.6.35 release candidates
From: KAMEZAWA Hiroyuki on 31 May 2010 21:00 On Mon, 31 May 2010 18:33:06 +0900 (JST) KOSAKI Motohiro <kosaki.motohiro(a)jp.fujitsu.com> wrote: > From: Oleg Nesterov <oleg(a)redhat.com> > Subject: oom: select_bad_process: check PF_KTHREAD instead of !mm to skip kthreads > > select_bad_process() thinks a kernel thread can't have ->mm != NULL, this > is not true due to use_mm(). > > Change the code to check PF_KTHREAD. > > Signed-off-by: Oleg Nesterov <oleg(a)redhat.com> > Acked-by: David Rientjes <rientjes(a)google.com> > Signed-off-by: KOSAKI Motohiro <kosaki.motohiro(a)jp.fujitsu.com> Reviewed-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu(a)jp.fujitsu.com> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: David Rientjes on 1 Jun 2010 16:40 On Mon, 31 May 2010, KOSAKI Motohiro wrote: > From: Oleg Nesterov <oleg(a)redhat.com> > Subject: oom: select_bad_process: check PF_KTHREAD instead of !mm to skip kthreads > > select_bad_process() thinks a kernel thread can't have ->mm != NULL, this > is not true due to use_mm(). > > Change the code to check PF_KTHREAD. > > Signed-off-by: Oleg Nesterov <oleg(a)redhat.com> > Acked-by: David Rientjes <rientjes(a)google.com> > Signed-off-by: KOSAKI Motohiro <kosaki.motohiro(a)jp.fujitsu.com> This is already pushed in my oom killer rewrite as patch 14/18 "check PF_KTHREAD instead of !mm to skip kthreads". This does not need to be merged immediately since it's not vital: use_mm() is only temporary state and these kthreads will once again be excluded when they call unuse_mm(). The worst case scenario here is that the oom killer will erroneously select one of these kthreads which cannot die and will need to reselect another task on its next call. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: David Rientjes on 1 Jun 2010 17:30 On Tue, 1 Jun 2010, Oleg Nesterov wrote: > But yes, I agree, the problem is minor. But nevertheless it is bug, > the longstanding bug with the simple fix. Why should we "hide" this fix > inside the long series of non-trivial patches which rewrite oom-killer? > And it is completely orthogonal to other changes. > Again, the question is whether or not the fix is rc material or not, otherwise there's no difference in the route that it gets upstream: the patch is duplicated in both series. If you feel that this minor issue (which has never been reported in at least the last three years and doesn't have any side effects other than a couple of millisecond delay until unuse_mm() when the oom killer will kill something else) should be addressed in 2.6.35-rc2, then that's a conversation to be had with Andrew. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Minchan Kim on 2 Jun 2010 11:40 On Mon, May 31, 2010 at 06:33:06PM +0900, KOSAKI Motohiro wrote: > From: Oleg Nesterov <oleg(a)redhat.com> > Subject: oom: select_bad_process: check PF_KTHREAD instead of !mm to skip kthreads > > select_bad_process() thinks a kernel thread can't have ->mm != NULL, this > is not true due to use_mm(). > > Change the code to check PF_KTHREAD. > > Signed-off-by: Oleg Nesterov <oleg(a)redhat.com> > Acked-by: David Rientjes <rientjes(a)google.com> > Signed-off-by: KOSAKI Motohiro <kosaki.motohiro(a)jp.fujitsu.com> Reviewed-by: Minchan Kim <minchan.kim(a)gmail.com> -- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: David Rientjes on 2 Jun 2010 17:10
On Wed, 2 Jun 2010, KOSAKI Motohiro wrote: > > Again, the question is whether or not the fix is rc material or not, > > otherwise there's no difference in the route that it gets upstream: the > > patch is duplicated in both series. If you feel that this minor issue > > (which has never been reported in at least the last three years and > > doesn't have any side effects other than a couple of millisecond delay > > until unuse_mm() when the oom killer will kill something else) should be > > addressed in 2.6.35-rc2, then that's a conversation to be had with Andrew. > > Well, we have bugfix-at-first development rule. Why do you refuse our > development process? > This isn't a bugfix, it simply prevents a recall to the oom killer after the kthread has called unuse_mm(). Please show where any side effects of oom killing a kthread, which cannot exit, as a result of use_mm() causes a problem _anywhere_. If that's the definition you have for a "bugfix," then I could certainly argue that some of my patches like "oom: filter tasks not sharing the same cpuset" is a bugfix because it allows needlessly killing tasks that won't free memory for current, or "oom: avoid oom killer for lowmem allocations" is a bugfix because it allows killing a task that won't free lowmem, etc. I agree that this is a nice patch to have to avoid that recall later, which is why I merged it into my patchset, but let's please be accurate about its impact. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |