Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758778Ab0FBVJ3 (ORCPT ); Wed, 2 Jun 2010 17:09:29 -0400 Received: from smtp-out.google.com ([216.239.44.51]:39549 "EHLO smtp-out.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758632Ab0FBVJ2 (ORCPT ); Wed, 2 Jun 2010 17:09:28 -0400 DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id: references:user-agent:mime-version:content-type:x-system-of-record; b=HEaVifmBm94dXgiq690p2ikcfIwEncj3vA5HR/NzcPFyvmXc9ZfxvTyPkYzgTUx++ a+bSRtyCwXX0Qf5bFY5zA== Date: Wed, 2 Jun 2010 14:09:23 -0700 (PDT) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com To: KOSAKI Motohiro cc: Oleg Nesterov , LKML , linux-mm , Andrew Morton , KAMEZAWA Hiroyuki , Nick Piggin Subject: Re: [PATCH 1/5] oom: select_bad_process: check PF_KTHREAD instead of !mm to skip kthreads In-Reply-To: <20100602223612.F52D.A69D9226@jp.fujitsu.com> Message-ID: References: <20100601212023.GA24917@redhat.com> <20100602223612.F52D.A69D9226@jp.fujitsu.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-System-Of-Record: true Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1708 Lines: 33 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/