From: "\"Zhou, Wenjian/周文剑\"" <zhouwj-fnst@cn.fujitsu.com>
To: Atsushi Kumagai <ats-kumagai@wm.jp.nec.com>
Cc: "kexec@lists.infradead.org" <kexec@lists.infradead.org>
Subject: Re: [PATCH 1/2] makedumpfile: Delete useless codes
Date: Tue, 30 Jun 2015 09:23:27 +0800 [thread overview]
Message-ID: <5591EF8F.4090201@cn.fujitsu.com> (raw)
In-Reply-To: <0910DD04CBD6DE4193FCF86B9C00BE9701DCA532@BPXM01GP.gisp.nec.co.jp>
On 06/29/2015 04:34 PM, Atsushi Kumagai wrote:
>> free_bitmap_buffer() in create_dump_bitmap() includes free_bitmap2_buffer().
>> So delete free_bitmap2_buffer().
>
> I thought that calling free_bitmap_buffer() at the end of create_dump_bitmap()
> is wrong, actually I fixed that in the devel branch like below:
>
> int
> create_dump_bitmap(void)
> {
> ...
> /* Should keep the buffer in the 1-cycle case. */
> if (info->flag_cyclic)
> free_bitmap_buffer();
>
> return ret;
> }
>
> The reason why we free the 2nd bitmap buffer once here is to reduce the
> memory consumption for the multi-cycle case in the kdump-compressed path,
> otherwise the bitmap buffers should be kept during execution.
>
I knew that, but I have one question.
Why it is needed in kdump-compressed but not in elf?
I noticed that in kdump-compressed, 2nd bitmap would also be re-prepared.
> If the buffers are kept as expected, there is no need to re-prepare the
> 2nd bitmap buffer as [PATCH 2/2].
>
> However, thanks to you, I notice that the current devel code still
> free the 2nd bitmap buffer in the ELF path even though it's necessary.
> So I'll fix it.
>
>
> Thanks
> Atsushi Kumagai
>
>> Signed-off-by: Zhou wenjian<zhouwj-fnst@cn.fujitsu.com>
>> ---
>> makedumpfile.c | 3 ---
>> 1 files changed, 0 insertions(+), 3 deletions(-)
>>
>> diff --git a/makedumpfile.c b/makedumpfile.c
>> index cc71f20..7f2949c 100644
>> --- a/makedumpfile.c
>> +++ b/makedumpfile.c
>> @@ -5933,9 +5933,6 @@ create_dump_bitmap(void)
>>
>> info->num_dumpable = get_num_dumpable_cyclic();
>>
>> - if (!info->flag_elf_dumpfile)
>> - free_bitmap2_buffer();
>> -
>> } else {
>> struct cycle cycle = {0};
>> first_cycle(0, info->max_mapnr,&cycle);
>> --
>> 1.7.1
>>
>>
>> _______________________________________________
>> kexec mailing list
>> kexec@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/kexec
--
Thanks
Zhou Wenjian
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2015-06-30 1:27 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-25 6:51 [PATCH 1/2] makedumpfile: Delete useless codes Zhou Wenjian
2015-06-25 6:51 ` [PATCH 2/2] makedumpfile: Fix a bug Zhou Wenjian
2015-06-29 8:34 ` [PATCH 1/2] makedumpfile: Delete useless codes Atsushi Kumagai
2015-06-30 1:23 ` "Zhou, Wenjian/周文剑" [this message]
2015-07-02 2:19 ` Atsushi Kumagai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5591EF8F.4090201@cn.fujitsu.com \
--to=zhouwj-fnst@cn.fujitsu.com \
--cc=ats-kumagai@wm.jp.nec.com \
--cc=kexec@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.