Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753937AbZAJEGg (ORCPT ); Fri, 9 Jan 2009 23:06:36 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751928AbZAJEGY (ORCPT ); Fri, 9 Jan 2009 23:06:24 -0500 Received: from smtp1.linux-foundation.org ([140.211.169.13]:44983 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751599AbZAJEGX (ORCPT ); Fri, 9 Jan 2009 23:06:23 -0500 Date: Fri, 9 Jan 2009 20:05:27 -0800 (PST) From: Linus Torvalds X-X-Sender: torvalds@localhost.localdomain To: Nicholas Miell cc: Ingo Molnar , jim owens , "H. Peter Anvin" , Chris Mason , Peter Zijlstra , Steven Rostedt , paulmck@linux.vnet.ibm.com, Gregory Haskins , Matthew Wilcox , Andi Kleen , Andrew Morton , Linux Kernel Mailing List , linux-fsdevel , linux-btrfs , Thomas Gleixner , Nick Piggin , Peter Morreale , Sven Dietrich Subject: Re: [patch] measurements, numbers about CONFIG_OPTIMIZE_INLINING=y impact In-Reply-To: <1231553564.2081.287.camel@entropy> Message-ID: References: <20090108141808.GC11629@elte.hu> <1231426014.11687.456.camel@twins> <1231434515.14304.27.camel@think.oraclecorp.com> <20090108183306.GA22916@elte.hu> <496648C7.5050700@zytor.com> <20090109130057.GA31845@elte.hu> <49675920.4050205@hp.com> <20090109153508.GA4671@elte.hu> <1231532276.2081.12.camel@entropy> <1231543701.2081.185.camel@entropy> <1231553564.2081.287.camel@entropy> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2577 Lines: 67 On Fri, 9 Jan 2009, Nicholas Miell wrote: > > It's only too big if you always keep it in memory, and I wasn't > suggesting that. Umm. We're talking kernel panics here. If it's not in memory, it doesn't exist as far as the kernel is concerned. If it doesn't exist, it cannot be reported. > My point was that you can get completely accurate stack traces in the > face of gcc's inlining, and that blaming gcc because you can't get good > stack traces because the kernel's debugging infrastructure isn't up to > snuff isn't exactly fair. No. I'm blaming inlining for making debugging harder. And that's ok - IF IT IS WORTH IT. It's not. Gcc inlining decisions suck. gcc inlines stuff that doesn't really help from being inlined, and doesn't inline stuff that _does_. What's so hard to accept in that? > And this is where we disagree. I believe that crash dumps should be the > norm and all the reasons you have against crash dumps in general are in > fact reasons against Linux's sub-par implementation of crash dumps in > specific. Good luck with that. Go ahead and try it. You'll find it wasn't so easy after all. > So, here I am, a non-enterprise end user with a non-stale kernel who'd > love to be able to give you a crash dump (or, more likely, a stack trace > created from that crash dump), but I can't because Linux crash dumps are > stuck in the enterprise ghetto. No, you're stuck because you apparently have your mind stuck on a crash-dump, and aren't willing to look at alternatives. You could use a network console. Trust me - if you can't set up a network console, you have no business mucking around with crash dumps. And if the crash is hard enough that you can't any output from that, again, a crash dump wouldn't exactly help, would it? > Hell, I'd be happy if I could get the the normal panic text written to > disk, but since the hard part is the actual writing to disk, there's no > reason not to do the full crash dump if you can. Umm. And why do you think the two have anything to do with each other? Only insane people want the kernel to write to disk when it has problems. Sane people try to write to something that doesn't potentially overwrite their data. Like the network. Which is there. Try it. Trust me, it's a _hell_ of a lot more likely to wotk than a crash dump. Linus -- 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/