From: Liu hua <sdu.liu@huawei.com>
To: Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp>,
"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>
Cc: "wangnan0@huawei.com" <wangnan0@huawei.com>,
"peifeiyue@huawei.com" <peifeiyue@huawei.com>,
"will.deacon@arm.com" <will.deacon@arm.com>,
"liusdu@126.com" <liusdu@126.com>,
"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH 2/2] makedumpfile: get additional information from vmcore
Date: Tue, 13 May 2014 15:25:26 +0800 [thread overview]
Message-ID: <5371C8E6.6080700@huawei.com> (raw)
In-Reply-To: <0910DD04CBD6DE4193FCF86B9C00BE97210369@BPXM01GP.gisp.nec.co.jp>
On 2014/5/13 14:21, Atsushi Kumagai wrote:
> Hello Liu,
>
>> Now we define MAX_PHYSMEM_BITS and SECTION_SIZE_BITS as
>> macros. So if we deal with vmcores with different values
>> of these two macros. We have to recompile makedumpfile.
>
> There are other macros which have architecture-specific values
> (e.g. __PAGE_OFFSET), and some functions are specific to each
> architecture (e.g. vaddr_to_paddr()), so we need recompilation
> eventually.
>
> OTOH, we already don't need recompilation for the same architecture
> since the values of such macros are defined for each kernel version
> like below:
>
> #ifdef __x86_64__
> ...
> #define _MAX_PHYSMEM_BITS_ORIG (40)
> #define _MAX_PHYSMEM_BITS_2_6_26 (44)
> #define _MAX_PHYSMEM_BITS_2_6_31 (46)
>
> So I don't think this patch is valuable.
Hi Atsushi,
For x86, it is not necessory. But for arm, different venders
may define different SECTION_SIZE_BITS. for example:
1 arch/arm/mach-clps711x/include/mach/memory.h
#define SECTION_SIZE_BITS 24
2 arch/arm/mach-exynos/include/mach/memory.h
#define SECTION_SIZE_BITS 28
4 arch/arm/mach-hisi/include/mach/memory.h
#define SECTION_SIZE_BITS 26
8 arch/arm/mach-sa1100/include/mach/memory.h
#define SECTION_SIZE_BITS 27
Perhaps we should find another way to let the userspace tools
to get the architecture-specific values.
Liu Hua
>
>
> Thanks
> Atsushi Kumagai
>
>> This patch makes makedumpfile get these two values from
>> vmcore info, if existing. It makes the makedumpfile more
>> compatible to vmcores with different section size.
>>
>> Signed-off-by: Liu Hua <sdu.liu@huawei.com>
>> ---
>> makedumpfile.c | 17 +++++++++++++++++
>> makedumpfile.h | 2 ++
>> 2 files changed, 19 insertions(+)
>>
>> diff --git a/makedumpfile.c b/makedumpfile.c
>> index 6cf6e24..3cdf323 100644
>> --- a/makedumpfile.c
>> +++ b/makedumpfile.c
>> @@ -2111,6 +2111,8 @@ read_vmcoreinfo(void)
>> READ_NUMBER("PG_slab", PG_slab);
>> READ_NUMBER("PG_buddy", PG_buddy);
>> READ_NUMBER("PG_hwpoison", PG_hwpoison);
>> + READ_NUMBER("SECTION_SIZE_BITS", SECTION_SIZE_BITS);
>> + READ_NUMBER("MAX_PHYSMEM_BITS", MAX_PHYSMEM_BITS);
>>
>> READ_SRCFILE("pud_t", pud_t);
>>
>> @@ -2998,6 +3000,18 @@ initialize_bitmap_memory(void)
>> }
>>
>> int
>> +calibrate_machdep_info(void)
>> +{
>> + if (NUMBER(MAX_PHYSMEM_BITS) > 0)
>> + info->max_physmem_bits = NUMBER(MAX_PHYSMEM_BITS);
>> +
>> + if (NUMBER(SECTION_SIZE_BITS) > 0)
>> + info->section_size_bits = NUMBER(SECTION_SIZE_BITS);
>> +
>> + return TRUE;
>> +}
>> +
>> +int
>> initial(void)
>> {
>> off_t offset;
>> @@ -3214,6 +3228,9 @@ out:
>> if (debug_info && !get_machdep_info())
>> return FALSE;
>>
>> + if (debug_info && !calibrate_machdep_info())
>> + return FALSE;
>> +
>> if (is_xen_memory() && !get_dom0_mapnr())
>> return FALSE;
>>
>> diff --git a/makedumpfile.h b/makedumpfile.h
>> index eb03688..7acb23a 100644
>> --- a/makedumpfile.h
>> +++ b/makedumpfile.h
>> @@ -1434,6 +1434,8 @@ struct number_table {
>> long PG_hwpoison;
>>
>> long PAGE_BUDDY_MAPCOUNT_VALUE;
>> + long SECTION_SIZE_BITS;
>> + long MAX_PHYSMEM_BITS;
>> };
>>
>> struct srcfile_table {
>> --
>> 1.9.0
>
> .
>
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: Liu hua <sdu.liu@huawei.com>
To: Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp>,
"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>
Cc: "will.deacon@arm.com" <will.deacon@arm.com>,
"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"wangnan0@huawei.com" <wangnan0@huawei.com>,
"peifeiyue@huawei.com" <peifeiyue@huawei.com>,
"liusdu@126.com" <liusdu@126.com>
Subject: Re: [RFC PATCH 2/2] makedumpfile: get additional information from vmcore
Date: Tue, 13 May 2014 15:25:26 +0800 [thread overview]
Message-ID: <5371C8E6.6080700@huawei.com> (raw)
In-Reply-To: <0910DD04CBD6DE4193FCF86B9C00BE97210369@BPXM01GP.gisp.nec.co.jp>
On 2014/5/13 14:21, Atsushi Kumagai wrote:
> Hello Liu,
>
>> Now we define MAX_PHYSMEM_BITS and SECTION_SIZE_BITS as
>> macros. So if we deal with vmcores with different values
>> of these two macros. We have to recompile makedumpfile.
>
> There are other macros which have architecture-specific values
> (e.g. __PAGE_OFFSET), and some functions are specific to each
> architecture (e.g. vaddr_to_paddr()), so we need recompilation
> eventually.
>
> OTOH, we already don't need recompilation for the same architecture
> since the values of such macros are defined for each kernel version
> like below:
>
> #ifdef __x86_64__
> ...
> #define _MAX_PHYSMEM_BITS_ORIG (40)
> #define _MAX_PHYSMEM_BITS_2_6_26 (44)
> #define _MAX_PHYSMEM_BITS_2_6_31 (46)
>
> So I don't think this patch is valuable.
Hi Atsushi,
For x86, it is not necessory. But for arm, different venders
may define different SECTION_SIZE_BITS. for example:
1 arch/arm/mach-clps711x/include/mach/memory.h
#define SECTION_SIZE_BITS 24
2 arch/arm/mach-exynos/include/mach/memory.h
#define SECTION_SIZE_BITS 28
4 arch/arm/mach-hisi/include/mach/memory.h
#define SECTION_SIZE_BITS 26
8 arch/arm/mach-sa1100/include/mach/memory.h
#define SECTION_SIZE_BITS 27
Perhaps we should find another way to let the userspace tools
to get the architecture-specific values.
Liu Hua
>
>
> Thanks
> Atsushi Kumagai
>
>> This patch makes makedumpfile get these two values from
>> vmcore info, if existing. It makes the makedumpfile more
>> compatible to vmcores with different section size.
>>
>> Signed-off-by: Liu Hua <sdu.liu@huawei.com>
>> ---
>> makedumpfile.c | 17 +++++++++++++++++
>> makedumpfile.h | 2 ++
>> 2 files changed, 19 insertions(+)
>>
>> diff --git a/makedumpfile.c b/makedumpfile.c
>> index 6cf6e24..3cdf323 100644
>> --- a/makedumpfile.c
>> +++ b/makedumpfile.c
>> @@ -2111,6 +2111,8 @@ read_vmcoreinfo(void)
>> READ_NUMBER("PG_slab", PG_slab);
>> READ_NUMBER("PG_buddy", PG_buddy);
>> READ_NUMBER("PG_hwpoison", PG_hwpoison);
>> + READ_NUMBER("SECTION_SIZE_BITS", SECTION_SIZE_BITS);
>> + READ_NUMBER("MAX_PHYSMEM_BITS", MAX_PHYSMEM_BITS);
>>
>> READ_SRCFILE("pud_t", pud_t);
>>
>> @@ -2998,6 +3000,18 @@ initialize_bitmap_memory(void)
>> }
>>
>> int
>> +calibrate_machdep_info(void)
>> +{
>> + if (NUMBER(MAX_PHYSMEM_BITS) > 0)
>> + info->max_physmem_bits = NUMBER(MAX_PHYSMEM_BITS);
>> +
>> + if (NUMBER(SECTION_SIZE_BITS) > 0)
>> + info->section_size_bits = NUMBER(SECTION_SIZE_BITS);
>> +
>> + return TRUE;
>> +}
>> +
>> +int
>> initial(void)
>> {
>> off_t offset;
>> @@ -3214,6 +3228,9 @@ out:
>> if (debug_info && !get_machdep_info())
>> return FALSE;
>>
>> + if (debug_info && !calibrate_machdep_info())
>> + return FALSE;
>> +
>> if (is_xen_memory() && !get_dom0_mapnr())
>> return FALSE;
>>
>> diff --git a/makedumpfile.h b/makedumpfile.h
>> index eb03688..7acb23a 100644
>> --- a/makedumpfile.h
>> +++ b/makedumpfile.h
>> @@ -1434,6 +1434,8 @@ struct number_table {
>> long PG_hwpoison;
>>
>> long PAGE_BUDDY_MAPCOUNT_VALUE;
>> + long SECTION_SIZE_BITS;
>> + long MAX_PHYSMEM_BITS;
>> };
>>
>> struct srcfile_table {
>> --
>> 1.9.0
>
> .
>
next prev parent reply other threads:[~2014-05-13 7:27 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-07 13:27 [RFC PATCH 0/2] transfer sparse memory related values Liu Hua
2014-05-07 13:27 ` Liu Hua
2014-05-07 13:27 ` [RFC PATCH 1/2] kdump: add sparse memory related values to vmcore Liu Hua
2014-05-07 13:27 ` Liu Hua
2014-05-07 13:27 ` [RFC PATCH 2/2] makedumpfile: get additional information from vmcore Liu Hua
2014-05-07 13:27 ` Liu Hua
2014-05-13 6:21 ` Atsushi Kumagai
2014-05-13 6:21 ` Atsushi Kumagai
2014-05-13 7:25 ` Liu hua [this message]
2014-05-13 7:25 ` Liu hua
2014-05-14 7:53 ` Atsushi Kumagai
2014-05-14 7:53 ` Atsushi Kumagai
2014-05-14 12:33 ` Liu hua
2014-05-14 12:33 ` Liu hua
2014-05-15 2:12 ` Atsushi Kumagai
2014-05-15 2:12 ` 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=5371C8E6.6080700@huawei.com \
--to=sdu.liu@huawei.com \
--cc=kexec@lists.infradead.org \
--cc=kumagai-atsushi@mxc.nes.nec.co.jp \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=liusdu@126.com \
--cc=peifeiyue@huawei.com \
--cc=wangnan0@huawei.com \
--cc=will.deacon@arm.com \
/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.