On Thu, Oct 07, 2004 at 07:00:19AM -0400, Steven M. Bellovin wrote:
> In message <pan.2004.10.07.08.45.42.597759@st.mff.cuni.cz>, Pavel Cahyna writes
> :
> >On Thu, 07 Oct 2004 06:39:11 +0000, David Young wrote:
> >
> >> It looks to me like it isn't too hard to make a sparse crashdump on x86
> >> that contains only the pages that are mapped into kernel virtual memory,
> >> the page directory and page table pages (PDP and PTPs).  Does a crashdump
> >> require any other pages?  I have a need for compact crashdumps, so I am
> >> going to work on this over the weekend.
> >
> >That would be great, thanks. BTW why does the crashdump contain the
> >physical memory instead of kernel virtual memory (/dev/kmem)? Is the
> >memory not mapped to kernel actually useful for something?
> >
> 
> At a guess, someone felt that when a system has just crashed it would 
> be unwise to rely on any more data from it than absolutely necessary.  
> What if the mapping tables were (part of?) the cause of the crash?

I'm pretty sure it was a simplicity thing, really.  For code that
needs to run in dire circumstances (How else could you describe
panic()?), simplicity is a goal to strive for.  Just whacking out
all the memory in the machine to the disk is simple.  Of course,
back then, machines didn't have 1G, 2GB, or 4Gb of memory (much
less even greater quantities in 64 bit machines).

I'm certain that going with sparse crash dumps will result in some
small number of kernel crashes that are impossible to debug, because
the spoor of the bug is in a page that isn't saved.  On the other
hand, I'd trade complete debuggability of all crash dumps for faster
crash dumps.  It's a drag when a 1.25GB machine is crashdumping...

One other thing to contemplate -- turning on disk write caches during
the crashdump, assuming that they can be turned off again near the
end of the crash dump.

-Kurt