* 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; +Cc: ptesarik, kexec, cpw
(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, kexec, cpw
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.