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 k...@.
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
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
