> 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@.
> 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.
>
