(2013/09/19 11:13), HATAYAMA Daisuke wrote: > (2013/09/18 12:00), Atsushi Kumagai wrote: >> (2013/08/30 10:33), HATAYAMA Daisuke wrote: >>> (2013/08/29 7:08), Cliff Wickman wrote: >>>> From: Cliff Wickman <cpw at sgi.com> >>>> >>>> I am submitting 6 patches that I have found helpful in speeding the dump >>>> process or clarifying the progress report. >>>> They are not a series, and should not be interdependent. But if you >>>> find any dependencies I apply them in this order: >>>> [PATCH] makedumpfile: reverse -c and -p if using snappy compression >>>> [PATCH] makedumpfile: use non-cyclic when possible >>>> [PATCH] makedumpfile: shorten cyclic exclude-unnecessary passes >>>> [PATCH] makedumpfile: shorten cyclic unnecessary-page scans >>>> [PATCH] makedumpfile: show needed memory >>>> [PATCH] makedumpfile: search for a debug vmlinux >>>> >>>> The last one (search for a debug vmlinux) is useful in identifying huge >>>> pages with the PG_head/PG-tail flags. There was a patch from Petr Tesarik >>>> that enables that huge page filtering. I don't think you are taking that one >>>> as-is, but are reworking it. Seems like Hatayama-san was doing that work. >>> >>> No. If I have good memory, Kumagai-san was investigating how to integrate >>> huge page filtering into current memory types currently supported by >>> makedumpfile. >> >> Yes, I was investigating it but I'm not working for it now. >> >> I think main features should work without vmlinux, >> but it was impossible about his patch as said by himself: >> >>> This patch depends on exporting the relevant PG_* flags from the >>> kernel (in VMCOREINFO), and that's where I got stuck, because depending >>> on the number of available bits for the page flags, the kernel either >>> has PG_head and PG_tail, or only PG_compound, so I needed a #ifdef, and >>> the kernel maintainers didn't like the conditional. >>> I can restart the discussion with kernel maintainers and see what I can do >> >> Therefore, I waited that his work is finished and I was going to continue >> my work, but I didn't say my thinking definitely, sorry. >> >> Anyway, I should cooperate with Petr to develop huge page filtering, >> so could you let me know the status of your work ? >> > > To whom do you make this question? It seems Cliff according to content of this question. > If so you should resend. If to me, I have not done huge page filtering work at all so far > as I already said in the previous mail in this thread. Sorry for confusing you, I asked Petr. According to Cliff's 1st mail: > From: Cliff Wickman <cpw at sgi.com> > > This fix comes from Petr Tesarik <ptesarik at suse.cz>, and was applied > to the SuSE version of makedumpfile. > I don't see it in the mmap version. > It is important to filtering out a great deal of user memory. > > But this from Petr on 5/15: >> This patch depends on exporting the relevant PG_* flags from the >> kernel (in VMCOREINFO), and that's where I got stuck, because depending >> on the number of available bits for the page flags, the kernel either >> has PG_head and PG_tail, or only PG_compound, so I needed a #ifdef, and >> the kernel maintainers didn't like the conditional. >> I can restart the discussion with kernel maintainers and see what I can do > So I'm not sending to the kexec list until he's ready. I understood Petr tried to add PG_* flags into VMCOREINFO, but it seems not completed in linux-next at this time. To prepare the flags is important to huge page filtering, I want to know the status of Petr's work. Thanks Atsushi Kumagai
