Re: minidump size on amd64

on 01/10/2010 10:43 Andriy Gapon said the following:
> The idea.  We dump contiguously only pages with PDEs (which means both valid and
> invalid PDEs), valid pages with PTEs are dumped the same way as data physical
> pages (i.e. via dump_add_page, etc); no fake PTEs for 2MB pages.
> PDE area of the dump takes about 20MB as opposed to 1GB for PTE area (the math
> is obvious, but just in case).
> 
> libkva is changed to treat former PTE area as PDE area and is also taught to
> understand PG_PS in PDE.
> There is now an overhead of having to first read a PTE page in V-to-P-to-offset
> lookup for !PG_PS case.  Perhaps we could cache all PTEs in memory and have a
> lookup table for them, but I didn't bother with this possibly premature
> optimization at this time.
> 
> There is an unrelated change in minidumpsys - "bitmap_frozen".
> I had to do it despite having a patch in my local tree to stop other CPUs on
> panic->dump.  Code in dump path (peripheral disk driver, CAM, SIM driver,
> something else?) seems to do some memory allocations and change dump bitmap,
> which leads to a mismatch between dump size and dump bitmap; and also
> potentially to inconsistencies in the bitmap itself.  So I decided that it's a
> good idea to freeze the bitmap once we decided what pages we want to dump.
> 
> Some variables and structure fields with 'pte' in them should probably be
> renamed to have 'pde' instead.

Here's an updated patch:
http://people.freebsd.org/~avg/amd64-minidump.3.diff

I went ahead and changed 'pte' to 'pde' in various names.
Also, I ditched somewhat questionable "bitmap_frozen" approach and instead opted
for restarting a dump on a size mismatch.  This was suggested by kib_at_.
Garret Cooper has pointed out some problems with bitmap_frozen approach.
I think that actual problem was a scenario where a dump is done, then the system
is allowed to continue and then another dump is done.  An exotic case perhaps? :-)

One probably desirable feature that is missing is backward compatibility in
libkvm.  If that is a showstopper, then I'll have to work on preserving it.

As usual, I will appreciate any feedback - reviews, testing, etc.
Thanks!
-- 
Andriy Gapon