* [PATCH 1/2] makedumpfile: Delete useless codes
@ 2015-06-25 6:51 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
0 siblings, 2 replies; 5+ messages in thread
From: Zhou Wenjian @ 2015-06-25 6:51 UTC (permalink / raw)
To: kexec; +Cc: Zhou wenjian
From: Zhou wenjian <zhouwj-fnst@cn.fujitsu.com>
free_bitmap_buffer() in create_dump_bitmap() includes free_bitmap2_buffer().
So delete free_bitmap2_buffer().
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
^ permalink raw reply related [flat|nested] 5+ messages in thread* [PATCH 2/2] makedumpfile: Fix a bug
2015-06-25 6:51 [PATCH 1/2] makedumpfile: Delete useless codes Zhou Wenjian
@ 2015-06-25 6:51 ` Zhou Wenjian
2015-06-29 8:34 ` [PATCH 1/2] makedumpfile: Delete useless codes Atsushi Kumagai
1 sibling, 0 replies; 5+ messages in thread
From: Zhou Wenjian @ 2015-06-25 6:51 UTC (permalink / raw)
To: kexec
In cyclic mode, when generating vmcore in elf format, info->bitmap2
is used but not prepared.
Signed-off-by: Zhou wenjian <zhouwj-fnst@cn.fujitsu.com>
---
makedumpfile.c | 15 +++++++++++++++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/makedumpfile.c b/makedumpfile.c
index 7f2949c..88e3389 100644
--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -6026,6 +6026,11 @@ get_loads_dumpfile_cyclic(void)
if (!(phnum = get_phnum_memory()))
return FALSE;
+ if (info->flag_cyclic) {
+ if (!prepare_bitmap2_buffer())
+ return FALSE;
+ }
+
for (i = 0; i < phnum; i++) {
if (!get_phdr_memory(i, &load))
return FALSE;
@@ -6069,6 +6074,11 @@ get_loads_dumpfile_cyclic(void)
}
}
+
+ if (info->flag_cyclic) {
+ free_bitmap2_buffer();
+ }
+
return num_new_load;
}
@@ -6108,6 +6118,11 @@ write_elf_pages_cyclic(struct cache_data *cd_header, struct cache_data *cd_page)
if (!(phnum = get_phnum_memory()))
return FALSE;
+ if (info->flag_cyclic) {
+ if (!prepare_bitmap2_buffer())
+ return FALSE;
+ }
+
gettimeofday(&tv_start, NULL);
for (i = 0; i < phnum; i++) {
--
1.7.1
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply related [flat|nested] 5+ messages in thread* RE: [PATCH 1/2] makedumpfile: Delete useless codes
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 ` Atsushi Kumagai
2015-06-30 1:23 ` "Zhou, Wenjian/周文剑"
1 sibling, 1 reply; 5+ messages in thread
From: Atsushi Kumagai @ 2015-06-29 8:34 UTC (permalink / raw)
To: zhouwj-fnst@cn.fujitsu.com; +Cc: kexec@lists.infradead.org
>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.
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
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [PATCH 1/2] makedumpfile: Delete useless codes
2015-06-29 8:34 ` [PATCH 1/2] makedumpfile: Delete useless codes Atsushi Kumagai
@ 2015-06-30 1:23 ` "Zhou, Wenjian/周文剑"
2015-07-02 2:19 ` Atsushi Kumagai
0 siblings, 1 reply; 5+ messages in thread
From: "Zhou, Wenjian/周文剑" @ 2015-06-30 1:23 UTC (permalink / raw)
To: Atsushi Kumagai; +Cc: kexec@lists.infradead.org
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
^ permalink raw reply [flat|nested] 5+ messages in thread* RE: [PATCH 1/2] makedumpfile: Delete useless codes
2015-06-30 1:23 ` "Zhou, Wenjian/周文剑"
@ 2015-07-02 2:19 ` Atsushi Kumagai
0 siblings, 0 replies; 5+ messages in thread
From: Atsushi Kumagai @ 2015-07-02 2:19 UTC (permalink / raw)
To: zhouwj-fnst@cn.fujitsu.com; +Cc: kexec@lists.infradead.org
>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.
The elf format doesn't include the 1st bitmap and is_dumpable() depends on
the 2nd bitmap, so there is no meaning to prepare the 1st bitmap buffer in elf.
OTOH, the kdump-compressed format include both 1st and 2nd bitmap, it's
necessary to prepare two buffers individually.
Thanks
Atsushi Kumagai
>> 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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2015-07-02 2:22 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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/周文剑"
2015-07-02 2:19 ` Atsushi Kumagai
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.