[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Time to deprecate crash dump support in stats tools (or KVM-grovelers in general)?
On Sat, Apr 05, 2008 at 12:43:57PM -0700, Jason Thorpe wrote:
> NetBSD has taken great steps recently to modernize its kernel. One of
> those steps has been to use per-CPU data for various subsystems (and
> the list of subsystems employing this technique to gain MP scalability
> is increasing).
> One of the upshots of moving to per-CPU data is that the data must be
> collated in order to be reported. This works well on live systems
> where sysctl is available. It doesn't work so well on crash dumps;
> the tools then have to know the specifics of how per-CPU data is
> managed for that particular subsystem and collate the data themselves.
"Must be" seems a bit strong. There should be a way to get both
the collated (collected per-CPU) data and the data from a single
CPU. Normally the aggregate will be the interesting number but
there maybe cases where a single CPU will be of interest. This
could/should be the case as MP support gets better.
> Given this, I think it's time to deprecate crash dump support in these
> tools (e.g. netstat(1)), and, more generally, deprecate KVM-groveling
> except in some very specific circumstances.
OK, per-CPU data is all well and good. I fail to see why it is
necessary to deprecate crash dump support or more generally
KVM-groveling. IRIX went to per-CPU data over 10 years ago and
preserved some crash dump support for things like netstat(1). Why
can't we? What am I missing?
[In another message, der Mouse has concerns about gdb scripts vs
kvm grovelers. Joerg Sonnenberger followed with comments about
duplicated code and how GDB was a huge win in his opinion.]
I'd echo der Mouse's comments/concerns. I don't see how trading
C, which maybe non-trivial, for non-trivial GDB scripts is a win.
If the C is truly duplicated then maybe it needs to live in a
common place like libkvm. Or is the concern that code is duplicated
between the kernel and user-space code?
Why tie analysis to GDB? What happens when we want to go to
abbreviated/sparse dumps because it is no longer practical to dump
multi-gigabyte kernel core images? Maybe we just won't worry about
supporting that many CPUs. Using GDB also assumes that you only
want to analyze non-stripped kernels, right?
Also how are the C code, as in netstat(1), and the GDB scripts
going to be kept in sync? Ideally don't you want them to both
display the information in the same way?
Main Index |
Thread Index |