Re: minidump size on amd64

Andriy Gapon wrote:
> 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.
>   


The kernel part of the patch looks good.  That said, I have one 
suggestion.  The current generation of AMD and Intel processors has 
support for 1GB pages.  If you want to make sure that this change will 
last us a long time, I would suggest translating the old trick of 
generating a fake page table page for 2MB pages into generating a fake 
page directory page for 1GB pages, rather than disposing of this code.

Alan