Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753672AbXLCBBF (ORCPT ); Sun, 2 Dec 2007 20:01:05 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750977AbXLCBAx (ORCPT ); Sun, 2 Dec 2007 20:00:53 -0500 Received: from pentafluge.infradead.org ([213.146.154.40]:56417 "EHLO pentafluge.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750838AbXLCBAw (ORCPT ); Sun, 2 Dec 2007 20:00:52 -0500 Date: Sun, 2 Dec 2007 16:59:13 -0800 From: Arjan van de Ven To: Andi Kleen Cc: Andi Kleen , Ingo Molnar , linux-kernel@vger.kernel.org, Andrew Morton , Thomas Gleixner Subject: Re: [feature] automatically detect hung TASK_UNINTERRUPTIBLE tasks Message-ID: <20071202165913.3eaebee6@laptopd505.fenrus.org> In-Reply-To: <20071203000741.GB26636@one.firstfloor.org> References: <20071201092037.GA32544@elte.hu> <20071202185945.GA25990@elte.hu> <20071202114152.3bf4332d@laptopd505.fenrus.org> <20071202200953.GA23994@one.firstfloor.org> <20071202202602.GA16480@elte.hu> <20071202204725.GA25891@one.firstfloor.org> <20071202144331.6abf1289@laptopd505.fenrus.org> <20071203000741.GB26636@one.firstfloor.org> Organization: Intel X-Mailer: Claws Mail 3.0.2 (GTK+ 2.12.1; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2291 Lines: 62 On Mon, 3 Dec 2007 01:07:41 +0100 Andi Kleen wrote: > > We really need to get better diagnostics for the > > bad-kernel-behavior-that-is-seen-as-bug cases. If we ever want to > > get to the scenario where we have a more or less robust measure of > > kernel quality (and we're not all that far off for several cases), > > one thing > > One measure to kernel quality is to recover well from IO errors > (like network problems or broken block devices) yes. and this patch will flag cases that don't (yet) work well > > This patch will likely work against that by breaking error paths. it won't break error paths, it will at most put a warning in the log. It doesn't kill or otherwise damage the system or process. > > > This patch is a step in the right direction there, by quite a > > lot. > > > > I really don't understand what your objection is to this patch... > > is it that an enterprise distro can't ship with it on? (Which is > > fine btw) > > Any distribution aimed at end users cannot ship with it on. That's a pretty bold statement; assuming that the TASK_KILLABLE patch is in, I don't see the problem. And even if a distro doesn't turn it on, I still don't see a problem; it's a diagnostics patch that people can turn on (even at runtime) if they see problems. > Also in general I have my doubts that the false positive:real bug > ratio of this warning is well balanced. I'll just have to disagree with you then; but both of us are making wild guesses. Only one way to get the real false positive percentage. > Just consider the original > example of dead network servers. Even in my relatively small > home network that that is a quite common occurrence. This patch > will break that all by throwing random backtraces when this > happens. 1) with TASK_KILLABLE that shouldn't happen 2) how does "throwing a backtrace" "break" things? -- If you want to reach me at my work email, use arjan@linux.intel.com For development, discussion and tips for power savings, visit http://www.lesswatts.org -- 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/