Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754743AbZAJGpO (ORCPT ); Sat, 10 Jan 2009 01:45:14 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752018AbZAJGo4 (ORCPT ); Sat, 10 Jan 2009 01:44:56 -0500 Received: from qmta04.emeryville.ca.mail.comcast.net ([76.96.30.40]:56231 "EHLO QMTA04.emeryville.ca.mail.comcast.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751892AbZAJGoz (ORCPT ); Sat, 10 Jan 2009 01:44:55 -0500 Subject: Re: [patch] measurements, numbers about CONFIG_OPTIMIZE_INLINING=y impact From: Nicholas Miell To: Linus Torvalds 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 In-Reply-To: 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> Content-Type: text/plain Date: Fri, 09 Jan 2009 22:44:49 -0800 Message-Id: <1231569889.4377.38.camel@entropy> Mime-Version: 1.0 X-Mailer: Evolution 2.24.2 (2.24.2-3.fc10) Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2868 Lines: 69 On Fri, 2009-01-09 at 20:05 -0800, Linus Torvalds wrote: > > 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. The idea was that the kernel would generate a crash dump and then after the reboot, a post-processing tool would do something with it. (e.g. run the dump through crash to get a stack trace using separate debug info or ship the entire dump off to a collection server or something). > > 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. netconsole requires a second computer. Feel free to mail me one. :) > 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. Well, yes, but that has everything to do with how terrible kdump is and nothing to do with the idea of crash dumps in general. Anyway, we've strayed off topic long enough, I'm sure everyone in the Cc list would be happy to stop getting an earful about the merits of crash dumps. -- Nicholas Miell -- 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/