On Wed, 14 May 2014 19:54:28 +0900 (JST) HATAYAMA Daisuke <d.hatayama at jp.fujitsu.com> wrote: > From: HATAYAMA Daisuke <d.hatayama at jp.fujitsu.com> > Subject: Re: [PATCH v3 1/2] Generic handling of multi-page exclusions > Date: Wed, 14 May 2014 19:37:23 +0900 > > > From: Atsushi Kumagai <kumagai-atsushi at mxc.nes.nec.co.jp> > > Subject: RE: [PATCH v3 1/2] Generic handling of multi-page exclusions > > Date: Wed, 14 May 2014 07:54:17 +0000 > > > >> Hello Petr, > >> > >>>When multiple pages are excluded from the dump, store the extents in > >>>struct cycle and check if anything is still pending on the next invocation > >>>of __exclude_unnecessary_pages. This assumes that: > >>> > >>> 1. after __exclude_unnecessary_pages is called for a struct mem_map_data > >>> that extends beyond the current cycle, it is not called again during > >>> that cycle, > >>> 2. in the next cycle, __exclude_unnecessary_pages is not called before > >>> this final struct mem_map_data. > >>> > >>>Both assumptions are met if struct mem_map_data segments: > >>> > >>> 1. do not overlap, > >>> 2. are sorted by physical address in ascending order. > >> > >> In ELF case, write_elf_pages_cyclic() processes PT_LOAD entries from > >> PT_LOAD(0), this can break both assumptions unluckily. > >> Actually this patch doesn't work on my machine: > >> > >> LOAD (0) > >> phys_start : 1000000 > >> phys_end : 182f000 > >> virt_start : ffffffff81000000 > >> virt_end : ffffffff8182f000 > >> LOAD (1) > >> phys_start : 1000 > >> phys_end : 9b400 > >> virt_start : ffff810000001000 > >> virt_end : ffff81000009b400 > >> LOAD (2) > >> phys_start : 100000 > >> phys_end : 27000000 > >> virt_start : ffff810000100000 > >> virt_end : ffff810027000000 > >> LOAD (3) > >> phys_start : 37000000 > >> phys_end : cff70000 > >> virt_start : ffff810037000000 > >> virt_end : ffff8100cff70000 > >> LOAD (4) > >> phys_start : 100000000 > >> phys_end : 170000000 > >> virt_start : ffff810100000000 > >> virt_end : ffff810170000000 > >> > >> > >> PT_LOAD(2) includes PT_LOAD(0) and there physical addresses aren't sorted. > >> > >> If there is the only "sort issue", it may easy to fix it with a new iterator > >> like "for_each_pt_load()", it iterates PT_LOAD entries in ascending order > >> by physical address. > >> However, I don't have a good idea to solve the overlap issue now... > >> > > > > Is it enough to merge them? Prepare a modified version of PTLOAD list > > and refer to it in actual processing. I think this also leads to > > cleaning up readpage_elf() that addresses some overapping memory map > > issue on ia64. > > > > I'm saying this because I don't find anywhere virt_start or virt_end > is used. We look up page table to convert virtual address to physical > address, not PT_LOAD entries. Oh, you're right! Why does the ordering of PT_LOAD segments matter here? If makedumpfile fails on your machine after applying my patches, then it's quite likely because of something else. FWIW I verified on a few dumpfiles that makedumpfile produced exactly the same output before and after applying the patches. OTOH I can see a warning when writing an ELF file. Before the patch: Excluding unnecessary pages : [100.0 %] \WARNING: PFN out of cycle range. (pfn:c00, cycle:[3fc00-3ffd0]) After the patch: Excluding unnecessary pages : [100.0 %] \WARNING: PFN out of cycle range. (pfn:26c00, cycle:[0-1ff6]) I'm unsure why there are out-of-cycle PFNs. Researching... Petr T
