x86/mm: Fix zone ranges boot printout
Subsystems (3)
PATCH v2 1/1 x86/mm: Fix zone ranges boot printout
Changelog:
V2:
-fix building warnings of min(...).
This is the usual physical memory layout boot printout:
...
[ 0.000000] Zone ranges: [ 0.000000] DMA [mem 0x00001000-0x00ffffff] [ 0.000000] DMA32 [mem 0x01000000-0xffffffff] [ 0.000000] Normal [mem 0x100000000-0xc3fffffff] [ 0.000000] Movable zone start for each node [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem 0x00001000-0x00099fff] [ 0.000000] node 0: [mem 0x00100000-0xbf78ffff] [ 0.000000] node 0: [mem 0x100000000-0x63fffffff] [ 0.000000] node 1: [mem 0x640000000-0xc3fffffff]
...
This is the log when we set "mem=2G" on the boot cmdline:
...
[ 0.000000] Zone ranges: [ 0.000000] DMA [mem 0x00001000-0x00ffffff] [ 0.000000] DMA32 [mem 0x01000000-0xffffffff] // should be 0x7fffffff, right? [ 0.000000] Normal empty [ 0.000000] Movable zone start for each node [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem 0x00001000-0x00099fff] [ 0.000000] node 0: [mem 0x00100000-0x7fffffff]
...
This patch fixes the printout, the following log shows the right ranges:
...
[ 0.000000] Zone ranges: [ 0.000000] DMA [mem 0x00001000-0x00ffffff] [ 0.000000] DMA32 [mem 0x01000000-0x7fffffff] [ 0.000000] Normal empty [ 0.000000] Movable zone start for each node [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem 0x00001000-0x00099fff] [ 0.000000] node 0: [mem 0x00100000-0x7fffffff]
...
--- arch/x86/mm/init.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
arch/x86/mm/init.c +4 -2
@@ -674,10 +674,12 @@ void __init zone_sizes_init(void)memset (max_zone_pfns,0 ,sizeof (max_zone_pfns));#ifdef CONFIG_ZONE_DMA - max_zone_pfns[ZONE_DMA ] =MAX_DMA_PFN ; + max_zone_pfns[ZONE_DMA] = min_t(unsigned long, + max_low_pfn,MAX_DMA_PFN );#endif #ifdef CONFIG_ZONE_DMA32 - max_zone_pfns[ZONE_DMA32 ] =MAX_DMA32_PFN ; + max_zone_pfns[ZONE_DMA32] = min_t(unsigned long, + max_low_pfn,MAX_DMA32_PFN );#endif max_zone_pfns[ZONE_NORMAL ] = max_low_pfn;#ifdef CONFIG_HIGHMEM
Signature · 1 line
2.0.0
Andrew Morton
maintainerQuoted 9 lines · On Tue, 9 Dec 2014 11:27:20 +0800 Xishi Qiu <[email protected]> wrote:
Changelog:
V2:
-fix building warnings of min(...)....
arch/x86/mm/init.c void __init zone_sizes_init(void) · line 678
Quoted 6 lines
arch/x86/mm/init.c +2
-1@@ -674,10 +674,12 @@ void __init zone_sizes_init(void)memset (max_zone_pfns,0 ,sizeof (max_zone_pfns));#ifdef CONFIG_ZONE_DMA - max_zone_pfns[ZONE_DMA ] =MAX_DMA_PFN ; + max_zone_pfns[ZONE_DMA] = min_t(unsigned long, + max_low_pfn,MAX_DMA_PFN );
MAX_DMA_PFN has type int.
arch/x86/mm/init.c void __init zone_sizes_init(void) · line 682
Quoted 5 lines
arch/x86/mm/init.c +2
-1#endif #ifdef CONFIG_ZONE_DMA32 - max_zone_pfns[ZONE_DMA32 ] =MAX_DMA32_PFN ; + max_zone_pfns[ZONE_DMA32] = min_t(unsigned long, + max_low_pfn,MAX_DMA32_PFN );
MAX_DMA32_PFN has type UL (I think?) so there's no need for min_t here.
arch/x86/mm/init.c void __init zone_sizes_init(void) · line 685
Quoted 3 lines
arch/x86/mm/init.c +0
-0#endif max_zone_pfns[ZONE_NORMAL ] = max_low_pfn;#ifdef CONFIG_HIGHMEM
Let's try to get the types correct, rather than hacking around fixing up fallout from earlier incorrect type choices?
What is the type of a pfn? Unsigned long, generally, when we bother thinking about it.
So how about we make MAX_DMA_PFN have type UL? I assume that fixes the warning?
If we do this, we should also be able to undo the min_t hackery in arch/x86/kernel/e820.c:memblock_find_dma_reserve().
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Quoted 36 lines · Andrew Morton
Quoted 9 lines · On Tue, 9 Dec 2014 11:27:20 +0800 Xishi Qiu <[email protected]> wrote:
Changelog:
V2:
-fix building warnings of min(...)....
arch/x86/mm/init.c void __init zone_sizes_init(void) · line 678
Quoted 6 lines
arch/x86/mm/init.c +2
-1@@ -674,10 +674,12 @@ void __init zone_sizes_init(void)memset (max_zone_pfns,0 ,sizeof (max_zone_pfns));#ifdef CONFIG_ZONE_DMA - max_zone_pfns[ZONE_DMA ] =MAX_DMA_PFN ; + max_zone_pfns[ZONE_DMA] = min_t(unsigned long, + max_low_pfn,MAX_DMA_PFN );
MAX_DMA_PFNhas type int.arch/x86/mm/init.c void __init zone_sizes_init(void) · line 682
Quoted 5 lines
arch/x86/mm/init.c +2
-1#endif #ifdef CONFIG_ZONE_DMA32 - max_zone_pfns[ZONE_DMA32 ] =MAX_DMA32_PFN ; + max_zone_pfns[ZONE_DMA32] = min_t(unsigned long, + max_low_pfn,MAX_DMA32_PFN );
MAX_DMA32_PFNhas type UL (I think?) so there's no need formin_there.arch/x86/mm/init.c void __init zone_sizes_init(void) · line 685
Quoted 3 lines
arch/x86/mm/init.c +0
-0#endif max_zone_pfns[ZONE_NORMAL ] = max_low_pfn;#ifdef CONFIG_HIGHMEM Let's try to get the types correct, rather than hacking around fixing up fallout from earlier incorrect type choices?
Quoted 9 lines
What is the type of a pfn? Unsigned long, generally, when we bother thinking about it.
So how about we make
MAX_DMA_PFNhave type UL? I assume that fixes the warning?If we do this, we should also be able to undo the
min_thackery in arch/x86/kernel/e820.c:memblock_find_dma_reserve().
Hi Andrew,
Thanks for your suggestion, I'll resend V3.
Thanks,
Xishi Qiu
Quoted 3 lines
.