Re: source line numbers with x86_64 modules? [Was: Re: [patch]measurements, numbers about CONFIG_OPTIMIZE_INLINING=y impact]
From: Ingo Molnar
Date: Sat Jan 10 2009 - 10:35:45 EST
* Mike Snitzer <snitzer@xxxxxxxxx> wrote:
> Yes, especially from someone who lacks the ability to properly configure
> kdump. I'm fairly surprised others are giving you a free pass when you
> keep asserting how broken kdump is with such hollow criticism. I rely
> heavily on kdump and it works quite well (kvm integration was lacking
> but has improved).
hm, you say you rely heavily on kdump ... for what exactly, and how does
it help the upstream Linux kernel?
I see a single fix from you in the whole repository:
ffc41cf: nbd: prevent sock_xmit from attempting to use a NULL socket
... and that single fix is a NULL pointer dereference that ought to have
been quite debuggable from a plain oops alone.
In practice i rarely see bugfixes that were debugged via kdump. Normal
oops based fixes outnumber kdump based fixes by a ratio of 1:100 or worse
- and kdump is readily available these days - just nobody configures it.
For example, in the whole kernel repo there's just 45 commits that mention
'kdump' [excluding those commits that develop kdump itself]:
$ git log --pretty=format:"%h: %s" --no-merges -i --grep="kdump" |
grep -viE 'kdump|kexec|dump|mem' | wc -l
45
Contrast that to the 1954 commits that contain the string 'oops' or
'crash':
$ git log --pretty=format:"%h: %s" --no-merges -i -E --grep="oops|crash" |
wc -l
5900
That's a ratio of 1:131. (and probably optimistic in favor of kdump.)
Note, i dont have any negative feelings towards kdump - some people use it
and enterprise folks with their frozen, immutable kernels love it - it
just has not yet given me a reason to have particularly positive feelings
towards it in the upstream kernel space.
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/