Re: Time to deprecate crash dump support in stats tools (or KVM-grovelers in general)?

[Brian Ginsbach <ginsbach%NetBSD.org@localhost>]

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.
> 
> Comments?
> 

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?

Brian