* A few patches to consider @ 2013-08-28 22:08 Cliff Wickman 2013-08-30 1:33 ` HATAYAMA Daisuke 0 siblings, 1 reply; 6+ messages in thread From: Cliff Wickman @ 2013-08-28 22:08 UTC (permalink / raw) To: d.hatayama, kumagai-atsushi; +Cc: kexec From: Cliff Wickman <cpw@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. That one is very important and I need to include Petr's version in any makedumpfile that we use in a very large system. I hope that one is coming along for inclusion in the next release. -Cliff Wickman _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: A few patches to consider 2013-08-28 22:08 A few patches to consider Cliff Wickman @ 2013-08-30 1:33 ` HATAYAMA Daisuke 2013-09-18 3:00 ` Atsushi Kumagai 0 siblings, 1 reply; 6+ messages in thread From: HATAYAMA Daisuke @ 2013-08-30 1:33 UTC (permalink / raw) To: Cliff Wickman; +Cc: kexec, kumagai-atsushi (2013/08/29 7:08), Cliff Wickman wrote: > From: Cliff Wickman <cpw@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. -- Thanks. HATAYAMA, Daisuke _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: A few patches to consider 2013-08-30 1:33 ` HATAYAMA Daisuke @ 2013-09-18 3:00 ` Atsushi Kumagai 2013-09-19 2:12 ` HATAYAMA Daisuke 0 siblings, 1 reply; 6+ messages in thread From: Atsushi Kumagai @ 2013-09-18 3:00 UTC (permalink / raw) To: d.hatayama; +Cc: ptesarik, kexec, cpw (2013/08/30 10:33), HATAYAMA Daisuke wrote: > (2013/08/29 7:08), Cliff Wickman wrote: >> From: Cliff Wickman <cpw@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 ? Thanks Atsushi Kumagai _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: A few patches to consider 2013-09-18 3:00 ` Atsushi Kumagai @ 2013-09-19 2:12 ` HATAYAMA Daisuke 2013-09-19 5:00 ` Atsushi Kumagai 0 siblings, 1 reply; 6+ messages in thread From: HATAYAMA Daisuke @ 2013-09-19 2:12 UTC (permalink / raw) To: Atsushi Kumagai; +Cc: kexec, ptesarik, cpw (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@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. -- Thanks. HATAYAMA, Daisuke _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: A few patches to consider 2013-09-19 2:12 ` HATAYAMA Daisuke @ 2013-09-19 5:00 ` Atsushi Kumagai 2013-09-20 20:52 ` Petr Tesarik 0 siblings, 1 reply; 6+ messages in thread From: Atsushi Kumagai @ 2013-09-19 5:00 UTC (permalink / raw) To: d.hatayama@jp.fujitsu.com Cc: ptesarik@suse.cz, kexec@lists.infradead.org, cpw@sgi.com (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@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@sgi.com> > > This fix comes from Petr Tesarik <ptesarik@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 _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: A few patches to consider 2013-09-19 5:00 ` Atsushi Kumagai @ 2013-09-20 20:52 ` Petr Tesarik 0 siblings, 0 replies; 6+ messages in thread From: Petr Tesarik @ 2013-09-20 20:52 UTC (permalink / raw) To: Atsushi Kumagai Cc: d.hatayama@jp.fujitsu.com, kexec@lists.infradead.org, cpw@sgi.com On Thu, 19 Sep 2013 05:00:02 +0000 Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp> wrote: > (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@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@sgi.com> > > > > This fix comes from Petr Tesarik <ptesarik@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. This got blocked when the maintainer of that subsystem didn't answer me what he considered a clean solution. And then it got sidetracked by other issues. I can resume from there, because I also need these flags properly exported in VMCOREINFO. OK, time to ask again. Petr T _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-09-20 20:52 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-08-28 22:08 A few patches to consider Cliff Wickman 2013-08-30 1:33 ` HATAYAMA Daisuke 2013-09-18 3:00 ` Atsushi Kumagai 2013-09-19 2:12 ` HATAYAMA Daisuke 2013-09-19 5:00 ` Atsushi Kumagai 2013-09-20 20:52 ` Petr Tesarik
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox