[PATCH] ARM: fix bug which VMALLOC_START is lowwer than 0xf0000000

[PATCH] ARM: fix bug which VMALLOC_START is lowwer than 0xf0000000

[Yongtaek Lee]

default value of vmalloc_min was set 0xf0000000 for ARM by commit
0536bdf3. But actually vmalloc_min is 0xef800000 not 0xf0000000.

VMALLOC_END - (240 << 20) - VMALLOC_OFFSET)
0xff000000 - 0x0f000000 - 0x00800000 = 0xef800000

In case of 768MB ram without CONFIG_HIGHMEM=y, last 8MB could not be
allocated. Kernel log also print out warning message as below.
"Truncating RAM at 80000000-afffffff to -af7fffff (vmalloc region overlap)."

Although it could be solved by state "vmalloc=size" in cmdline but i think
it would be better to change default value to 232 from 240.

Signed-off-by: Yongtaek Lee <ytk.lee@samsung.com>

---
 arch/arm/mm/mmu.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 8348ed6..9a1bab4 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -1040,12 +1040,12 @@ void __init debug_ll_io_init(void)
 #endif
 
 static void * __initdata vmalloc_min =
-	(void *)(VMALLOC_END - (240 << 20) - VMALLOC_OFFSET);
+	(void *)(VMALLOC_END - (232 << 20) - VMALLOC_OFFSET);
 
 /*
  * vmalloc=size forces the vmalloc area to be exactly 'size'
  * bytes. This can be used to increase (or decrease) the vmalloc
- * area - the default is 240m.
+ * area - the default is 232m.
  */
 static int __init early_vmalloc(char *arg)
 {
-- 
1.7.9

[PATCH] ARM: fix bug which VMALLOC_START is lowwer than 0xf0000000

[Yongtaek Lee]

default value of vmalloc_min was set 0xf0000000 for ARM by commit
0536bdf3. But actually vmalloc_min is 0xef800000 not 0xf0000000.

VMALLOC_END - (240 << 20) - VMALLOC_OFFSET)
0xff000000 - 0x0f000000 - 0x00800000 = 0xef800000

In case of 768MB ram without CONFIG_HIGHMEM=y, last 8MB could not be
allocated. Kernel log also print out warning message as below.
"Truncating RAM at 80000000-afffffff to -af7fffff (vmalloc region overlap)."

Although it could be solved by state "vmalloc=size" in cmdline but i think
it would be better to change default value to 232 from 240.

Signed-off-by: Yongtaek Lee <ytk.lee@samsung.com>

---
 arch/arm/mm/mmu.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 8348ed6..9a1bab4 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -1040,12 +1040,12 @@ void __init debug_ll_io_init(void)
 #endif
 
 static void * __initdata vmalloc_min =
-	(void *)(VMALLOC_END - (240 << 20) - VMALLOC_OFFSET);
+	(void *)(VMALLOC_END - (232 << 20) - VMALLOC_OFFSET);
 
 /*
  * vmalloc=size forces the vmalloc area to be exactly 'size'
  * bytes. This can be used to increase (or decrease) the vmalloc
- * area - the default is 240m.
+ * area - the default is 232m.
  */
 static int __init early_vmalloc(char *arg)
 {
-- 
1.7.9

[PATCH] ARM: fix bug which lowmem size is limited to 760MB

[Yongtaek Lee]

default value of VMALLOC_START was set 0xf0000000 for ARM by commit
0536bdf3. It leads lowmem end address 0xef800000 not 0xf0000000.

VMALLOC_END - (240 << 20) - VMALLOC_OFFSET)
0xff000000 - 0x0f000000 - 0x00800000 = 0xef800000

In case of 768MB ram without CONFIG_HIGHMEM=y, last 8MB could not be
allocated. Kernel log also print out warning message as below.
"Truncating RAM at 80000000-afffffff to -af7fffff (vmalloc region overlap)."

Although it could be solved by state "vmalloc=size" in cmdline but i think
it would be better to change default value to 232 from 240.

Signed-off-by: Yongtaek Lee <ytk.lee@samsung.com>
---
 arch/arm/mm/mmu.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 8348ed6..9a1bab4 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -1040,12 +1040,12 @@ void __init debug_ll_io_init(void)
 #endif
 
 static void * __initdata vmalloc_min =
-	(void *)(VMALLOC_END - (240 << 20) - VMALLOC_OFFSET);
+	(void *)(VMALLOC_END - (232 << 20) - VMALLOC_OFFSET);
 
 /*
  * vmalloc=size forces the vmalloc area to be exactly 'size'
  * bytes. This can be used to increase (or decrease) the vmalloc
- * area - the default is 240m.
+ * area - the default is 232m.
  */
 static int __init early_vmalloc(char *arg)
 {
-- 
1.7.9

[PATCH] ARM: fix bug which lowmem size is limited to 760MB

[Yongtaek Lee]

default value of VMALLOC_START was set 0xf0000000 for ARM by commit
0536bdf3. It leads lowmem end address 0xef800000 not 0xf0000000.

VMALLOC_END - (240 << 20) - VMALLOC_OFFSET)
0xff000000 - 0x0f000000 - 0x00800000 = 0xef800000

In case of 768MB ram without CONFIG_HIGHMEM=y, last 8MB could not be
allocated. Kernel log also print out warning message as below.
"Truncating RAM at 80000000-afffffff to -af7fffff (vmalloc region overlap)."

Although it could be solved by state "vmalloc=size" in cmdline but i think
it would be better to change default value to 232 from 240.

Signed-off-by: Yongtaek Lee <ytk.lee@samsung.com>
---
 arch/arm/mm/mmu.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 8348ed6..9a1bab4 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -1040,12 +1040,12 @@ void __init debug_ll_io_init(void)
 #endif
 
 static void * __initdata vmalloc_min =
-	(void *)(VMALLOC_END - (240 << 20) - VMALLOC_OFFSET);
+	(void *)(VMALLOC_END - (232 << 20) - VMALLOC_OFFSET);
 
 /*
  * vmalloc=size forces the vmalloc area to be exactly 'size'
  * bytes. This can be used to increase (or decrease) the vmalloc
- * area - the default is 240m.
+ * area - the default is 232m.
  */
 static int __init early_vmalloc(char *arg)
 {
-- 
1.7.9

Re: [PATCH] ARM: fix bug which VMALLOC_START is lowwer than 0xf0000000

[Russell King - ARM Linux]

On Thu, Sep 03, 2015 at 11:24:47AM +0900, Yongtaek Lee wrote:
> default value of vmalloc_min was set 0xf0000000 for ARM by commit
> 0536bdf3. But actually vmalloc_min is 0xef800000 not 0xf0000000.
> 
> VMALLOC_END - (240 << 20) - VMALLOC_OFFSET)
> 0xff000000 - 0x0f000000 - 0x00800000 = 0xef800000
> 
> In case of 768MB ram without CONFIG_HIGHMEM=y, last 8MB could not be
> allocated. Kernel log also print out warning message as below.
> "Truncating RAM at 80000000-afffffff to -af7fffff (vmalloc region overlap)."
> 
> Although it could be solved by state "vmalloc=size" in cmdline but i think
> it would be better to change default value to 232 from 240.
> 
> Signed-off-by: Yongtaek Lee <ytk.lee@samsung.com>

I fail to see what the problem is here.  You're adjusting the size of the
vmalloc space to accomodate the size of RAM you have.  That's not a bug.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH] ARM: fix bug which VMALLOC_START is lowwer than 0xf0000000

[Russell King - ARM Linux]

On Thu, Sep 03, 2015 at 11:24:47AM +0900, Yongtaek Lee wrote:
> default value of vmalloc_min was set 0xf0000000 for ARM by commit
> 0536bdf3. But actually vmalloc_min is 0xef800000 not 0xf0000000.
> 
> VMALLOC_END - (240 << 20) - VMALLOC_OFFSET)
> 0xff000000 - 0x0f000000 - 0x00800000 = 0xef800000
> 
> In case of 768MB ram without CONFIG_HIGHMEM=y, last 8MB could not be
> allocated. Kernel log also print out warning message as below.
> "Truncating RAM at 80000000-afffffff to -af7fffff (vmalloc region overlap)."
> 
> Although it could be solved by state "vmalloc=size" in cmdline but i think
> it would be better to change default value to 232 from 240.
> 
> Signed-off-by: Yongtaek Lee <ytk.lee@samsung.com>

I fail to see what the problem is here.  You're adjusting the size of the
vmalloc space to accomodate the size of RAM you have.  That's not a bug.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: Re: [PATCH] ARM: fix bug which VMALLOC_START is lowwer than 0xf0000000

[Yongtaek Lee]

> On Thu, Sep 03, 2015 at 11:24:47AM +0900, Yongtaek Lee wrote:
> > default value of vmalloc_min was set 0xf0000000 for ARM by commit
> > 0536bdf3. But actually vmalloc_min is 0xef800000 not 0xf0000000.
> > 
> > VMALLOC_END - (240 << 20) - VMALLOC_OFFSET)
> > 0xff000000 - 0x0f000000 - 0x00800000 = 0xef800000
> > 
> > In case of 768MB ram without CONFIG_HIGHMEM=y, last 8MB could not be
> > allocated. Kernel log also print out warning message as below.
> > "Truncating RAM at 80000000-afffffff to -af7fffff (vmalloc region overlap)."
> > 
> > Although it could be solved by state "vmalloc=size" in cmdline but i think
> > it would be better to change default value to 232 from 240.
> > 
> > Signed-off-by: Yongtaek Lee <ytk.lee@samsung.com>
>
> I fail to see what the problem is here.  You're adjusting the size of the
> vmalloc space to accomodate the size of RAM you have.  That's not a bug.

I will explain more about problem. 
It could happened with 768MB RAM device and CONFIG_HIGHMEN is not set.
"vmalloc=size" also not stated so that default value of vmalloc_min will be 
used to calculate lowmem end address. 

before applying patch.
[    0.000000]  [0:        swapper:    0] [c0] Truncating RAM at 80000000-afffffff to -af7fffff (vmalloc region overlap).

[    0.000000]  [0:        swapper:    0] [c0] Memory: 106MB 652MB = 758MB total
[    0.000000]  [0:        swapper:    0] [c0] Memory: 669892k/669892k available, 108348k reserved, 0K highmem
[    0.000000]  [0:        swapper:    0] [c0] Virtual kernel memory layout:
[    0.000000]  [0:        swapper:    0]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]  [0:        swapper:    0]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
[    0.000000]  [0:        swapper:    0]     vmalloc : 0xf0000000 - 0xff000000   ( 240 MB)
[    0.000000]  [0:        swapper:    0]     lowmem  : 0xc0000000 - 0xef800000   ( 760 MB)
[    0.000000]  [0:        swapper:    0]     modules : 0xbf000000 - 0xc0000000   (  16 MB)
[    0.000000]  [0:        swapper:    0]       .text : 0xc0008000 - 0xc09bbee0   (9936 kB)
[    0.000000]  [0:        swapper:    0]       .init : 0xc09bc000 - 0xc0a2b740   ( 446 kB)
[    0.000000]  [0:        swapper:    0]       .data : 0xc0a2c000 - 0xc0ac4088   ( 609 kB)
[    0.000000]  [0:        swapper:    0]        .bss : 0xc0ac4088 - 0xc0d3e7b4   (2538 kB)

after applying patch. 
[    0.000000]  [0:        swapper:    0] [c0] Memory: 106MB 660MB = 766MB total
[    0.000000]  [0:        swapper:    0] [c0] Memory: 678004k/678004k available, 108428k reserved, 0K highmem
[    0.000000]  [0:        swapper:    0] [c0] Virtual kernel memory layout:
[    0.000000]  [0:        swapper:    0]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]  [0:        swapper:    0]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
[    0.000000]  [0:        swapper:    0]     vmalloc : 0xf0800000 - 0xff000000   ( 232 MB)
[    0.000000]  [0:        swapper:    0]     lowmem  : 0xc0000000 - 0xf0000000   ( 768 MB)
[    0.000000]  [0:        swapper:    0]     modules : 0xbf000000 - 0xc0000000   (  16 MB)
[    0.000000]  [0:        swapper:    0]       .text : 0xc0008000 - 0xc09bbee0   (9936 kB)
[    0.000000]  [0:        swapper:    0]       .init : 0xc09bc000 - 0xc0a2b740   ( 446 kB)
[    0.000000]  [0:        swapper:    0]       .data : 0xc0a2c000 - 0xc0ac4088   ( 609 kB)
[    0.000000]  [0:        swapper:    0]        .bss : 0xc0ac4088 - 0xc0d3e7b4   (2538 kB)

As i know "vmalloc=size" is not mandatory so that i think default value of
vmalloc_min is wrong. 

[PATCH] ARM: fix bug which VMALLOC_START is lowwer than 0xf0000000

[Yongtaek Lee]

> On Thu, Sep 03, 2015 at 11:24:47AM +0900, Yongtaek Lee wrote:
> > default value of vmalloc_min was set 0xf0000000 for ARM by commit
> > 0536bdf3. But actually vmalloc_min is 0xef800000 not 0xf0000000.
> > 
> > VMALLOC_END - (240 << 20) - VMALLOC_OFFSET)
> > 0xff000000 - 0x0f000000 - 0x00800000 = 0xef800000
> > 
> > In case of 768MB ram without CONFIG_HIGHMEM=y, last 8MB could not be
> > allocated. Kernel log also print out warning message as below.
> > "Truncating RAM at 80000000-afffffff to -af7fffff (vmalloc region overlap)."
> > 
> > Although it could be solved by state "vmalloc=size" in cmdline but i think
> > it would be better to change default value to 232 from 240.
> > 
> > Signed-off-by: Yongtaek Lee <ytk.lee@samsung.com>
>
> I fail to see what the problem is here.  You're adjusting the size of the
> vmalloc space to accomodate the size of RAM you have.  That's not a bug.

I will explain more about problem. 
It could happened with 768MB RAM device and CONFIG_HIGHMEN is not set.
"vmalloc=size" also not stated so that default value of vmalloc_min will be 
used to calculate lowmem end address. 

before applying patch.
[    0.000000]  [0:        swapper:    0] [c0] Truncating RAM at 80000000-afffffff to -af7fffff (vmalloc region overlap).

[    0.000000]  [0:        swapper:    0] [c0] Memory: 106MB 652MB = 758MB total
[    0.000000]  [0:        swapper:    0] [c0] Memory: 669892k/669892k available, 108348k reserved, 0K highmem
[    0.000000]  [0:        swapper:    0] [c0] Virtual kernel memory layout:
[    0.000000]  [0:        swapper:    0]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]  [0:        swapper:    0]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
[    0.000000]  [0:        swapper:    0]     vmalloc : 0xf0000000 - 0xff000000   ( 240 MB)
[    0.000000]  [0:        swapper:    0]     lowmem  : 0xc0000000 - 0xef800000   ( 760 MB)
[    0.000000]  [0:        swapper:    0]     modules : 0xbf000000 - 0xc0000000   (  16 MB)
[    0.000000]  [0:        swapper:    0]       .text : 0xc0008000 - 0xc09bbee0   (9936 kB)
[    0.000000]  [0:        swapper:    0]       .init : 0xc09bc000 - 0xc0a2b740   ( 446 kB)
[    0.000000]  [0:        swapper:    0]       .data : 0xc0a2c000 - 0xc0ac4088   ( 609 kB)
[    0.000000]  [0:        swapper:    0]        .bss : 0xc0ac4088 - 0xc0d3e7b4   (2538 kB)

after applying patch. 
[    0.000000]  [0:        swapper:    0] [c0] Memory: 106MB 660MB = 766MB total
[    0.000000]  [0:        swapper:    0] [c0] Memory: 678004k/678004k available, 108428k reserved, 0K highmem
[    0.000000]  [0:        swapper:    0] [c0] Virtual kernel memory layout:
[    0.000000]  [0:        swapper:    0]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]  [0:        swapper:    0]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
[    0.000000]  [0:        swapper:    0]     vmalloc : 0xf0800000 - 0xff000000   ( 232 MB)
[    0.000000]  [0:        swapper:    0]     lowmem  : 0xc0000000 - 0xf0000000   ( 768 MB)
[    0.000000]  [0:        swapper:    0]     modules : 0xbf000000 - 0xc0000000   (  16 MB)
[    0.000000]  [0:        swapper:    0]       .text : 0xc0008000 - 0xc09bbee0   (9936 kB)
[    0.000000]  [0:        swapper:    0]       .init : 0xc09bc000 - 0xc0a2b740   ( 446 kB)
[    0.000000]  [0:        swapper:    0]       .data : 0xc0a2c000 - 0xc0ac4088   ( 609 kB)
[    0.000000]  [0:        swapper:    0]        .bss : 0xc0ac4088 - 0xc0d3e7b4   (2538 kB)

As i know "vmalloc=size" is not mandatory so that i think default value of
vmalloc_min is wrong. 

Re: Re: [PATCH] ARM: fix bug which VMALLOC_START is lowwer than 0xf0000000

[Lucas Stach]

Am Donnerstag, den 03.09.2015, 17:28 +0900 schrieb Yongtaek Lee:
> > On Thu, Sep 03, 2015 at 11:24:47AM +0900, Yongtaek Lee wrote:
> > > default value of vmalloc_min was set 0xf0000000 for ARM by commit
> > > 0536bdf3. But actually vmalloc_min is 0xef800000 not 0xf0000000.
> > > 
> > > VMALLOC_END - (240 << 20) - VMALLOC_OFFSET)
> > > 0xff000000 - 0x0f000000 - 0x00800000 = 0xef800000
> > > 
> > > In case of 768MB ram without CONFIG_HIGHMEM=y, last 8MB could not be
> > > allocated. Kernel log also print out warning message as below.
> > > "Truncating RAM at 80000000-afffffff to -af7fffff (vmalloc region overlap)."
> > > 
> > > Although it could be solved by state "vmalloc=size" in cmdline but i think
> > > it would be better to change default value to 232 from 240.
> > > 
> > > Signed-off-by: Yongtaek Lee <ytk.lee@samsung.com>
> >
> > I fail to see what the problem is here.  You're adjusting the size of the
> > vmalloc space to accomodate the size of RAM you have.  That's not a bug.
> 
> I will explain more about problem. 
> It could happened with 768MB RAM device and CONFIG_HIGHMEN is not set.
> "vmalloc=size" also not stated so that default value of vmalloc_min will be 
> used to calculate lowmem end address. 

> before applying patch.
> [    0.000000]  [0:        swapper:    0] [c0] Truncating RAM at 80000000-afffffff to -af7fffff (vmalloc region overlap).
> 
> [    0.000000]  [0:        swapper:    0] [c0] Memory: 106MB 652MB = 758MB total
> [    0.000000]  [0:        swapper:    0] [c0] Memory: 669892k/669892k available, 108348k reserved, 0K highmem
> [    0.000000]  [0:        swapper:    0] [c0] Virtual kernel memory layout:
> [    0.000000]  [0:        swapper:    0]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
> [    0.000000]  [0:        swapper:    0]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
> [    0.000000]  [0:        swapper:    0]     vmalloc : 0xf0000000 - 0xff000000   ( 240 MB)
> [    0.000000]  [0:        swapper:    0]     lowmem  : 0xc0000000 - 0xef800000   ( 760 MB)
> [    0.000000]  [0:        swapper:    0]     modules : 0xbf000000 - 0xc0000000   (  16 MB)
> [    0.000000]  [0:        swapper:    0]       .text : 0xc0008000 - 0xc09bbee0   (9936 kB)
> [    0.000000]  [0:        swapper:    0]       .init : 0xc09bc000 - 0xc0a2b740   ( 446 kB)
> [    0.000000]  [0:        swapper:    0]       .data : 0xc0a2c000 - 0xc0ac4088   ( 609 kB)
> [    0.000000]  [0:        swapper:    0]        .bss : 0xc0ac4088 - 0xc0d3e7b4   (2538 kB)
> 
> after applying patch. 
> [    0.000000]  [0:        swapper:    0] [c0] Memory: 106MB 660MB = 766MB total
> [    0.000000]  [0:        swapper:    0] [c0] Memory: 678004k/678004k available, 108428k reserved, 0K highmem
> [    0.000000]  [0:        swapper:    0] [c0] Virtual kernel memory layout:
> [    0.000000]  [0:        swapper:    0]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
> [    0.000000]  [0:        swapper:    0]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
> [    0.000000]  [0:        swapper:    0]     vmalloc : 0xf0800000 - 0xff000000   ( 232 MB)
> [    0.000000]  [0:        swapper:    0]     lowmem  : 0xc0000000 - 0xf0000000   ( 768 MB)
> [    0.000000]  [0:        swapper:    0]     modules : 0xbf000000 - 0xc0000000   (  16 MB)
> [    0.000000]  [0:        swapper:    0]       .text : 0xc0008000 - 0xc09bbee0   (9936 kB)
> [    0.000000]  [0:        swapper:    0]       .init : 0xc09bc000 - 0xc0a2b740   ( 446 kB)
> [    0.000000]  [0:        swapper:    0]       .data : 0xc0a2c000 - 0xc0ac4088   ( 609 kB)
> [    0.000000]  [0:        swapper:    0]        .bss : 0xc0ac4088 - 0xc0d3e7b4   (2538 kB)
> 
> As i know "vmalloc=size" is not mandatory so that i think default value of
> vmalloc_min is wrong. 
> 
So, if we go and apply your logic to a 1GB system we should resize the
vmalloc area to 0 bytes in order to avoid RAM truncation without
CONFIG_HIGHMEM?

Sorry, but the only sane options here are to either live with the
truncation, enable CONFIG_HIGHMEM, or set vmalloc size manually.
Changing a default value that affects everyone for the benefit of your
specific use-case isn't a sane option.

Regards,
Lucas
-- 
Pengutronix e.K.             | Lucas Stach                 |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

[PATCH] ARM: fix bug which VMALLOC_START is lowwer than 0xf0000000

[Lucas Stach]

Am Donnerstag, den 03.09.2015, 17:28 +0900 schrieb Yongtaek Lee:
> > On Thu, Sep 03, 2015 at 11:24:47AM +0900, Yongtaek Lee wrote:
> > > default value of vmalloc_min was set 0xf0000000 for ARM by commit
> > > 0536bdf3. But actually vmalloc_min is 0xef800000 not 0xf0000000.
> > > 
> > > VMALLOC_END - (240 << 20) - VMALLOC_OFFSET)
> > > 0xff000000 - 0x0f000000 - 0x00800000 = 0xef800000
> > > 
> > > In case of 768MB ram without CONFIG_HIGHMEM=y, last 8MB could not be
> > > allocated. Kernel log also print out warning message as below.
> > > "Truncating RAM at 80000000-afffffff to -af7fffff (vmalloc region overlap)."
> > > 
> > > Although it could be solved by state "vmalloc=size" in cmdline but i think
> > > it would be better to change default value to 232 from 240.
> > > 
> > > Signed-off-by: Yongtaek Lee <ytk.lee@samsung.com>
> >
> > I fail to see what the problem is here.  You're adjusting the size of the
> > vmalloc space to accomodate the size of RAM you have.  That's not a bug.
> 
> I will explain more about problem. 
> It could happened with 768MB RAM device and CONFIG_HIGHMEN is not set.
> "vmalloc=size" also not stated so that default value of vmalloc_min will be 
> used to calculate lowmem end address. 

> before applying patch.
> [    0.000000]  [0:        swapper:    0] [c0] Truncating RAM at 80000000-afffffff to -af7fffff (vmalloc region overlap).
> 
> [    0.000000]  [0:        swapper:    0] [c0] Memory: 106MB 652MB = 758MB total
> [    0.000000]  [0:        swapper:    0] [c0] Memory: 669892k/669892k available, 108348k reserved, 0K highmem
> [    0.000000]  [0:        swapper:    0] [c0] Virtual kernel memory layout:
> [    0.000000]  [0:        swapper:    0]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
> [    0.000000]  [0:        swapper:    0]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
> [    0.000000]  [0:        swapper:    0]     vmalloc : 0xf0000000 - 0xff000000   ( 240 MB)
> [    0.000000]  [0:        swapper:    0]     lowmem  : 0xc0000000 - 0xef800000   ( 760 MB)
> [    0.000000]  [0:        swapper:    0]     modules : 0xbf000000 - 0xc0000000   (  16 MB)
> [    0.000000]  [0:        swapper:    0]       .text : 0xc0008000 - 0xc09bbee0   (9936 kB)
> [    0.000000]  [0:        swapper:    0]       .init : 0xc09bc000 - 0xc0a2b740   ( 446 kB)
> [    0.000000]  [0:        swapper:    0]       .data : 0xc0a2c000 - 0xc0ac4088   ( 609 kB)
> [    0.000000]  [0:        swapper:    0]        .bss : 0xc0ac4088 - 0xc0d3e7b4   (2538 kB)
> 
> after applying patch. 
> [    0.000000]  [0:        swapper:    0] [c0] Memory: 106MB 660MB = 766MB total
> [    0.000000]  [0:        swapper:    0] [c0] Memory: 678004k/678004k available, 108428k reserved, 0K highmem
> [    0.000000]  [0:        swapper:    0] [c0] Virtual kernel memory layout:
> [    0.000000]  [0:        swapper:    0]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
> [    0.000000]  [0:        swapper:    0]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
> [    0.000000]  [0:        swapper:    0]     vmalloc : 0xf0800000 - 0xff000000   ( 232 MB)
> [    0.000000]  [0:        swapper:    0]     lowmem  : 0xc0000000 - 0xf0000000   ( 768 MB)
> [    0.000000]  [0:        swapper:    0]     modules : 0xbf000000 - 0xc0000000   (  16 MB)
> [    0.000000]  [0:        swapper:    0]       .text : 0xc0008000 - 0xc09bbee0   (9936 kB)
> [    0.000000]  [0:        swapper:    0]       .init : 0xc09bc000 - 0xc0a2b740   ( 446 kB)
> [    0.000000]  [0:        swapper:    0]       .data : 0xc0a2c000 - 0xc0ac4088   ( 609 kB)
> [    0.000000]  [0:        swapper:    0]        .bss : 0xc0ac4088 - 0xc0d3e7b4   (2538 kB)
> 
> As i know "vmalloc=size" is not mandatory so that i think default value of
> vmalloc_min is wrong. 
> 
So, if we go and apply your logic to a 1GB system we should resize the
vmalloc area to 0 bytes in order to avoid RAM truncation without
CONFIG_HIGHMEM?

Sorry, but the only sane options here are to either live with the
truncation, enable CONFIG_HIGHMEM, or set vmalloc size manually.
Changing a default value that affects everyone for the benefit of your
specific use-case isn't a sane option.

Regards,
Lucas
-- 
Pengutronix e.K.             | Lucas Stach                 |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

Re: Re: Re: [PATCH] ARM: fix bug which VMALLOC_START is lowwer than 0xf0000000

[Yongtaek Lee]

> So, if we go and apply your logic to a 1GB system we should resize the
> vmalloc area to 0 bytes in order to avoid RAM truncation without
> CONFIG_HIGHMEM?

As you already know, CONFIG_HIGHMEM option is necessary if RAM is
more than 1GB. So no need to resize vmalloc area to 0. 

> Sorry, but the only sane options here are to either live with the
> truncation, enable CONFIG_HIGHMEM, or set vmalloc size manually.
> Changing a default value that affects everyone for the benefit of your
> specific use-case isn't a sane option.

[PATCH] ARM: fix bug which VMALLOC_START is lowwer than 0xf0000000

[Yongtaek Lee]

> So, if we go and apply your logic to a 1GB system we should resize the
> vmalloc area to 0 bytes in order to avoid RAM truncation without
> CONFIG_HIGHMEM?

As you already know, CONFIG_HIGHMEM option is necessary if RAM is
more than 1GB. So no need to resize vmalloc area to 0. 

> Sorry, but the only sane options here are to either live with the
> truncation, enable CONFIG_HIGHMEM, or set vmalloc size manually.
> Changing a default value that affects everyone for the benefit of your
> specific use-case isn't a sane option.

Re: Re: [PATCH] ARM: fix bug which VMALLOC_START is lowwer than 0xf0000000

[Russell King - ARM Linux]

On Thu, Sep 03, 2015 at 10:34:32AM +0200, Lucas Stach wrote:
> Am Donnerstag, den 03.09.2015, 17:28 +0900 schrieb Yongtaek Lee:
> > As i know "vmalloc=size" is not mandatory so that i think default value of
> > vmalloc_min is wrong. 
> > 
> So, if we go and apply your logic to a 1GB system we should resize the
> vmalloc area to 0 bytes in order to avoid RAM truncation without
> CONFIG_HIGHMEM?
> 
> Sorry, but the only sane options here are to either live with the
> truncation, enable CONFIG_HIGHMEM, or set vmalloc size manually.
> Changing a default value that affects everyone for the benefit of your
> specific use-case isn't a sane option.

Exactly right.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH] ARM: fix bug which VMALLOC_START is lowwer than 0xf0000000

[Russell King - ARM Linux]

On Thu, Sep 03, 2015 at 10:34:32AM +0200, Lucas Stach wrote:
> Am Donnerstag, den 03.09.2015, 17:28 +0900 schrieb Yongtaek Lee:
> > As i know "vmalloc=size" is not mandatory so that i think default value of
> > vmalloc_min is wrong. 
> > 
> So, if we go and apply your logic to a 1GB system we should resize the
> vmalloc area to 0 bytes in order to avoid RAM truncation without
> CONFIG_HIGHMEM?
> 
> Sorry, but the only sane options here are to either live with the
> truncation, enable CONFIG_HIGHMEM, or set vmalloc size manually.
> Changing a default value that affects everyone for the benefit of your
> specific use-case isn't a sane option.

Exactly right.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: Re: Re: [PATCH] ARM: fix bug which VMALLOC_START is lowwer than 0xf0000000

[Russell King - ARM Linux]

On Thu, Sep 03, 2015 at 05:43:29PM +0900, Yongtaek Lee wrote:
> > So, if we go and apply your logic to a 1GB system we should resize the
> > vmalloc area to 0 bytes in order to avoid RAM truncation without
> > CONFIG_HIGHMEM?
> 
> As you already know, CONFIG_HIGHMEM option is necessary if RAM is
> more than 1GB. So no need to resize vmalloc area to 0. 

Wrong, there is no such "rule".

If we apply that rule, then if you have 1GB of RAM, it will fill from
0xc0000000 to 0xffffffff inclusive.  There will be _zero_ bytes of
vmalloc space.  There will be _zero_ bytes of IO mappings.  There won't
even be a vectors page, so the kernel _will_ crash on the first exception.
The "rule" you think exists doesn't because it is wrong.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH] ARM: fix bug which VMALLOC_START is lowwer than 0xf0000000

[Russell King - ARM Linux]

On Thu, Sep 03, 2015 at 05:43:29PM +0900, Yongtaek Lee wrote:
> > So, if we go and apply your logic to a 1GB system we should resize the
> > vmalloc area to 0 bytes in order to avoid RAM truncation without
> > CONFIG_HIGHMEM?
> 
> As you already know, CONFIG_HIGHMEM option is necessary if RAM is
> more than 1GB. So no need to resize vmalloc area to 0. 

Wrong, there is no such "rule".

If we apply that rule, then if you have 1GB of RAM, it will fill from
0xc0000000 to 0xffffffff inclusive.  There will be _zero_ bytes of
vmalloc space.  There will be _zero_ bytes of IO mappings.  There won't
even be a vectors page, so the kernel _will_ crash on the first exception.
The "rule" you think exists doesn't because it is wrong.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH] ARM: fix bug which lowmem size is limited to 760MB

[Yongtaek Lee]

> Wrong, there is no such "rule".

> If we apply that rule, then if you have 1GB of RAM, it will fill from
> 0xc0000000 to 0xffffffff inclusive.  There will be _zero_ bytes of
> vmalloc space.  There will be _zero_ bytes of IO mappings.  There won't
> even be a vectors page, so the kernel _will_ crash on the first exception.
> The "rule" you think exists doesn't because it is wrong.

I am sorry disturb you again. 
I am confusing after reading your comment. 

So i summarize my opinion again. 

Current status.

768MB, no CONFIG_HIGHMEM and no vmalloc=size
lowmem : 0MB ~ 760MB
vmalloc : 768MB ~ VMALLOC_END
  => waste 8MB because 760MB ~ 768MB is hole

1GB, no CONFIG_HIGHMEM and no vmalloc=size
lowmem : 0MB ~ 760MB
vmalloc : 768MB ~ VMALLOC_END
 => waste 264MB, so we need to enable CONFIG_HIGHMEM to use full memory. 
highmem : 264MB if enable CONFIG_HIGHMEM 

after applying patch. 

768MB, no CONFIG_HIGHMEM and no vmalloc=size
lowmem : 0MB ~ 768MB
vmalloc : 776MB ~ VMALLOC_END
 => use 768MB fully

1GB, no CONFIG_HIGHMEM and no vmalloc=size
lowmem : 0MB ~ 768MB
vmalloc : 776MB ~ VMALLOC_END
 => waste 256MB, so we need to enable CONFIG_HIGHMEM to use full memory. 
highmem : 256MB if enable CONFIG_HIGHMEM
 => it will not fill from 0xc0000000 to 0xffffffff

My opinion is not that vmalloc area size should be changed for all cases(512M, 768M, 1GB, 2GB, etc.). 
If we change default value from 240MB to 232MB, it could covor all cases without 
any other changes so that i have suggested this patch. 


As we already talked there are 3 cases with 768MB
1. live with the truncation => waste 8MB so that it will not be acceptable. 
2. enable CONFIG_HIGHMEM => mm point of view it could make overhead because there is only 8MB(very small) in highmem. 
3. set vmalloc size manually => I already mentioned it could fix issue but 
if default value is suitable then it is needless.  

Anyway please think again which size is more efficient for all cases. 
If you still think this patch is not acceptable i will accept your decision. 

Thank you for your comment.

[PATCH] ARM: fix bug which lowmem size is limited to 760MB

[Yongtaek Lee]

> Wrong, there is no such "rule".

> If we apply that rule, then if you have 1GB of RAM, it will fill from
> 0xc0000000 to 0xffffffff inclusive.  There will be _zero_ bytes of
> vmalloc space.  There will be _zero_ bytes of IO mappings.  There won't
> even be a vectors page, so the kernel _will_ crash on the first exception.
> The "rule" you think exists doesn't because it is wrong.

I am sorry disturb you again. 
I am confusing after reading your comment. 

So i summarize my opinion again. 

Current status.

768MB, no CONFIG_HIGHMEM and no vmalloc=size
lowmem : 0MB ~ 760MB
vmalloc : 768MB ~ VMALLOC_END
  => waste 8MB because 760MB ~ 768MB is hole

1GB, no CONFIG_HIGHMEM and no vmalloc=size
lowmem : 0MB ~ 760MB
vmalloc : 768MB ~ VMALLOC_END
 => waste 264MB, so we need to enable CONFIG_HIGHMEM to use full memory. 
highmem : 264MB if enable CONFIG_HIGHMEM 

after applying patch. 

768MB, no CONFIG_HIGHMEM and no vmalloc=size
lowmem : 0MB ~ 768MB
vmalloc : 776MB ~ VMALLOC_END
 => use 768MB fully

1GB, no CONFIG_HIGHMEM and no vmalloc=size
lowmem : 0MB ~ 768MB
vmalloc : 776MB ~ VMALLOC_END
 => waste 256MB, so we need to enable CONFIG_HIGHMEM to use full memory. 
highmem : 256MB if enable CONFIG_HIGHMEM
 => it will not fill from 0xc0000000 to 0xffffffff

My opinion is not that vmalloc area size should be changed for all cases(512M, 768M, 1GB, 2GB, etc.). 
If we change default value from 240MB to 232MB, it could covor all cases without 
any other changes so that i have suggested this patch. 


As we already talked there are 3 cases with 768MB
1. live with the truncation => waste 8MB so that it will not be acceptable. 
2. enable CONFIG_HIGHMEM => mm point of view it could make overhead because there is only 8MB(very small) in highmem. 
3. set vmalloc size manually => I already mentioned it could fix issue but 
if default value is suitable then it is needless.  

Anyway please think again which size is more efficient for all cases. 
If you still think this patch is not acceptable i will accept your decision. 

Thank you for your comment.

Re: [PATCH] ARM: fix bug which lowmem size is limited to 760MB

[Nicolas Pitre]

On Thu, 3 Sep 2015, Yongtaek Lee wrote:

> So i summarize my opinion again. 
> 
> Current status.
> 
> 768MB, no CONFIG_HIGHMEM and no vmalloc=size
> lowmem : 0MB ~ 760MB
> vmalloc : 768MB ~ VMALLOC_END
>   => waste 8MB because 760MB ~ 768MB is hole
> 
> 1GB, no CONFIG_HIGHMEM and no vmalloc=size
> lowmem : 0MB ~ 760MB
> vmalloc : 768MB ~ VMALLOC_END
>  => waste 264MB, so we need to enable CONFIG_HIGHMEM to use full memory. 
> highmem : 264MB if enable CONFIG_HIGHMEM 
> 
> after applying patch. 
> 
> 768MB, no CONFIG_HIGHMEM and no vmalloc=size
> lowmem : 0MB ~ 768MB
> vmalloc : 776MB ~ VMALLOC_END
>  => use 768MB fully
> 
> 1GB, no CONFIG_HIGHMEM and no vmalloc=size
> lowmem : 0MB ~ 768MB
> vmalloc : 776MB ~ VMALLOC_END
>  => waste 256MB, so we need to enable CONFIG_HIGHMEM to use full memory. 
> highmem : 256MB if enable CONFIG_HIGHMEM
>  => it will not fill from 0xc0000000 to 0xffffffff
> 
> My opinion is not that vmalloc area size should be changed for all cases(512M, 768M, 1GB, 2GB, etc.). 
> If we change default value from 240MB to 232MB, it could covor all cases without 
> any other changes so that i have suggested this patch. 
> 
> 
> As we already talked there are 3 cases with 768MB
> 1. live with the truncation => waste 8MB so that it will not be acceptable. 
> 2. enable CONFIG_HIGHMEM => mm point of view it could make overhead because there is only 8MB(very small) in highmem. 
> 3. set vmalloc size manually => I already mentioned it could fix issue but 
> if default value is suitable then it is needless.  

This is indeed unfortunate that the current value does not fit well with 
a 768MB configuration.  However this default value has been in place for 
many years now without problems on existing targets.  There is always a 
slight possibility that some targets might have issues with a reduced 
vmalloc size if we were to change it now.

If 768MB targets were common place then it could be worth changing the 
default vmalloc size to accommodate this memory size and testing all the 
other targets to make sure no regressions are introduced.  But given it 
is easy to change the default via the kernel cmdline, and that you lose 
only 8 MB otherwise, I don't think it is worth the trouble and/or the 
risk.


Nicolas

[PATCH] ARM: fix bug which lowmem size is limited to 760MB

[Nicolas Pitre]

On Thu, 3 Sep 2015, Yongtaek Lee wrote:

> So i summarize my opinion again. 
> 
> Current status.
> 
> 768MB, no CONFIG_HIGHMEM and no vmalloc=size
> lowmem : 0MB ~ 760MB
> vmalloc : 768MB ~ VMALLOC_END
>   => waste 8MB because 760MB ~ 768MB is hole
> 
> 1GB, no CONFIG_HIGHMEM and no vmalloc=size
> lowmem : 0MB ~ 760MB
> vmalloc : 768MB ~ VMALLOC_END
>  => waste 264MB, so we need to enable CONFIG_HIGHMEM to use full memory. 
> highmem : 264MB if enable CONFIG_HIGHMEM 
> 
> after applying patch. 
> 
> 768MB, no CONFIG_HIGHMEM and no vmalloc=size
> lowmem : 0MB ~ 768MB
> vmalloc : 776MB ~ VMALLOC_END
>  => use 768MB fully
> 
> 1GB, no CONFIG_HIGHMEM and no vmalloc=size
> lowmem : 0MB ~ 768MB
> vmalloc : 776MB ~ VMALLOC_END
>  => waste 256MB, so we need to enable CONFIG_HIGHMEM to use full memory. 
> highmem : 256MB if enable CONFIG_HIGHMEM
>  => it will not fill from 0xc0000000 to 0xffffffff
> 
> My opinion is not that vmalloc area size should be changed for all cases(512M, 768M, 1GB, 2GB, etc.). 
> If we change default value from 240MB to 232MB, it could covor all cases without 
> any other changes so that i have suggested this patch. 
> 
> 
> As we already talked there are 3 cases with 768MB
> 1. live with the truncation => waste 8MB so that it will not be acceptable. 
> 2. enable CONFIG_HIGHMEM => mm point of view it could make overhead because there is only 8MB(very small) in highmem. 
> 3. set vmalloc size manually => I already mentioned it could fix issue but 
> if default value is suitable then it is needless.  

This is indeed unfortunate that the current value does not fit well with 
a 768MB configuration.  However this default value has been in place for 
many years now without problems on existing targets.  There is always a 
slight possibility that some targets might have issues with a reduced 
vmalloc size if we were to change it now.

If 768MB targets were common place then it could be worth changing the 
default vmalloc size to accommodate this memory size and testing all the 
other targets to make sure no regressions are introduced.  But given it 
is easy to change the default via the kernel cmdline, and that you lose 
only 8 MB otherwise, I don't think it is worth the trouble and/or the 
risk.


Nicolas

Re: [PATCH] ARM: fix bug which lowmem size is limited to 760MB

[Arnd Bergmann]

On Thursday 03 September 2015 21:24:00 Nicolas Pitre wrote:
> If 768MB targets were common place then it could be worth changing the 
> default vmalloc size to accommodate this memory size and testing all the 
> other targets to make sure no regressions are introduced.  But given it 
> is easy to change the default via the kernel cmdline, and that you lose 
> only 8 MB otherwise, I don't think it is worth the trouble and/or the 
> risk.

Agreed.

Given how much more common 1GB hardware configurations are compared to 768MB
configuration, we could however think about adding a VMSPLIT_3G_OPT option
that x86 has (also VMSPLIT_2_75G on ARCH_TILE), to allow using the entire
1GB of lowmem without going all the way to VMSPLIT_2G. That option would
also let us use the entire 768MB on the machines that 	Yongtaek Lee is
interested in.

	Arnd

[PATCH] ARM: fix bug which lowmem size is limited to 760MB

[Arnd Bergmann]

On Thursday 03 September 2015 21:24:00 Nicolas Pitre wrote:
> If 768MB targets were common place then it could be worth changing the 
> default vmalloc size to accommodate this memory size and testing all the 
> other targets to make sure no regressions are introduced.  But given it 
> is easy to change the default via the kernel cmdline, and that you lose 
> only 8 MB otherwise, I don't think it is worth the trouble and/or the 
> risk.

Agreed.

Given how much more common 1GB hardware configurations are compared to 768MB
configuration, we could however think about adding a VMSPLIT_3G_OPT option
that x86 has (also VMSPLIT_2_75G on ARCH_TILE), to allow using the entire
1GB of lowmem without going all the way to VMSPLIT_2G. That option would
also let us use the entire 768MB on the machines that 	Yongtaek Lee is
interested in.

	Arnd

Re: [PATCH] ARM: fix bug which lowmem size is limited to 760MB

[Nicolas Pitre]

On Mon, 7 Sep 2015, Arnd Bergmann wrote:

> Given how much more common 1GB hardware configurations are compared to 768MB
> configuration, we could however think about adding a VMSPLIT_3G_OPT option
> that x86 has (also VMSPLIT_2_75G on ARCH_TILE), to allow using the entire
> 1GB of lowmem without going all the way to VMSPLIT_2G. That option would
> also let us use the entire 768MB on the machines that 	Yongtaek Lee is
> interested in.

That's easy enough:

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 0d1b717e1e..a63970f211 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1470,6 +1470,8 @@ choice
 
 	config VMSPLIT_3G
 		bool "3G/1G user/kernel split"
+	config VMSPLIT_3G_OPT
+		bool "3G/1G user/kernel split (for full 1G low memory)"
 	config VMSPLIT_2G
 		bool "2G/2G user/kernel split"
 	config VMSPLIT_1G
@@ -1481,6 +1483,7 @@ config PAGE_OFFSET
 	default PHYS_OFFSET if !MMU
 	default 0x40000000 if VMSPLIT_1G
 	default 0x80000000 if VMSPLIT_2G
+	default 0xAF000000 if VMSPLIT_3G_OPT
 	default 0xC0000000
 
 config NR_CPUS


That shifts the risk to user space though.  But if there is a regression 
there, it will manifest itself on all systems and not only with some 
particular hardware.


Nicolas

[PATCH] ARM: fix bug which lowmem size is limited to 760MB

[Nicolas Pitre]

On Mon, 7 Sep 2015, Arnd Bergmann wrote:

> Given how much more common 1GB hardware configurations are compared to 768MB
> configuration, we could however think about adding a VMSPLIT_3G_OPT option
> that x86 has (also VMSPLIT_2_75G on ARCH_TILE), to allow using the entire
> 1GB of lowmem without going all the way to VMSPLIT_2G. That option would
> also let us use the entire 768MB on the machines that 	Yongtaek Lee is
> interested in.

That's easy enough:

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 0d1b717e1e..a63970f211 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1470,6 +1470,8 @@ choice
 
 	config VMSPLIT_3G
 		bool "3G/1G user/kernel split"
+	config VMSPLIT_3G_OPT
+		bool "3G/1G user/kernel split (for full 1G low memory)"
 	config VMSPLIT_2G
 		bool "2G/2G user/kernel split"
 	config VMSPLIT_1G
@@ -1481,6 +1483,7 @@ config PAGE_OFFSET
 	default PHYS_OFFSET if !MMU
 	default 0x40000000 if VMSPLIT_1G
 	default 0x80000000 if VMSPLIT_2G
+	default 0xAF000000 if VMSPLIT_3G_OPT
 	default 0xC0000000
 
 config NR_CPUS


That shifts the risk to user space though.  But if there is a regression 
there, it will manifest itself on all systems and not only with some 
particular hardware.


Nicolas

Re: [PATCH] ARM: fix bug which lowmem size is limited to 760MB

[Arnd Bergmann]

On Monday 07 September 2015 11:34:36 Nicolas Pitre wrote:
> 
> That shifts the risk to user space though.  But if there is a regression 
> there, it will manifest itself on all systems and not only with some 
> particular hardware.

I'd consider that a good thing, as it makes it easier to test when
you see the same behavior on systems with any memory size.

	Arnd

[PATCH] ARM: fix bug which lowmem size is limited to 760MB

[Arnd Bergmann]

On Monday 07 September 2015 11:34:36 Nicolas Pitre wrote:
> 
> That shifts the risk to user space though.  But if there is a regression 
> there, it will manifest itself on all systems and not only with some 
> particular hardware.

I'd consider that a good thing, as it makes it easier to test when
you see the same behavior on systems with any memory size.

	Arnd

Re: [PATCH] ARM: fix bug which lowmem size is limited to 760MB

[Nicolas Pitre]

On Mon, 7 Sep 2015, Arnd Bergmann wrote:

> On Monday 07 September 2015 11:34:36 Nicolas Pitre wrote:
> > 
> > That shifts the risk to user space though.  But if there is a regression 
> > there, it will manifest itself on all systems and not only with some 
> > particular hardware.
> 
> I'd consider that a good thing, as it makes it easier to test when
> you see the same behavior on systems with any memory size.

Sure, that was my point, although I admitedly didn't say it clearly.


Nicolas

[PATCH] ARM: fix bug which lowmem size is limited to 760MB

[Nicolas Pitre]

On Mon, 7 Sep 2015, Arnd Bergmann wrote:

> On Monday 07 September 2015 11:34:36 Nicolas Pitre wrote:
> > 
> > That shifts the risk to user space though.  But if there is a regression 
> > there, it will manifest itself on all systems and not only with some 
> > particular hardware.
> 
> I'd consider that a good thing, as it makes it easier to test when
> you see the same behavior on systems with any memory size.

Sure, that was my point, although I admitedly didn't say it clearly.


Nicolas

Re: [PATCH] ARM: fix bug which lowmem size is limited to 760MB

[Nicolas Pitre]

On Mon, 7 Sep 2015, Arnd Bergmann wrote:

> On Thursday 03 September 2015 21:24:00 Nicolas Pitre wrote:
> > If 768MB targets were common place then it could be worth changing the 
> > default vmalloc size to accommodate this memory size and testing all the 
> > other targets to make sure no regressions are introduced.  But given it 
> > is easy to change the default via the kernel cmdline, and that you lose 
> > only 8 MB otherwise, I don't think it is worth the trouble and/or the 
> > risk.
> 
> Agreed.

Well... I think there is a better solution.

Instead of shrinking the vmalloc size, we should instead move 
VMALLOC_END and keep the vmalloc size unchanged.  That also makes for 
nicer address alignment in a subsequent CONFIG_VMSPLIT_3G_OPT patch.

----- >8
ARM: move VMALLOC_END up from 0xff000000 to 0xff800000

There is a 12MB unused region in our memory map between the vmalloc and
fixmap areas. This became unused with commit e9da6e9905e6, confirmed with
commit 64d3b6a3f480.

We also have a 8MB guard area before the vmalloc area.  With the default
240MB vmalloc area size, that puts the end of low memory at 0xef800000
which is unfortunate for 768MB machines where 8MB of RAM is lost to
himem.

Let's move VMALLOC_END to 0xff800000 so the guard area won't chop the
top of the 768MB lomem area while keeping the default vmalloc area size
unchanged and also preserving a gap between the vmalloc and fixmap
areas.

Signed-off-by: Nicolas Pitre <nico@linaro.org>

diff --git a/Documentation/arm/memory.txt b/Documentation/arm/memory.txt
index 4178ebda6e..546a39048e 100644
--- a/Documentation/arm/memory.txt
+++ b/Documentation/arm/memory.txt
@@ -54,7 +54,7 @@ VMALLOC_START	VMALLOC_END-1	vmalloc() / ioremap() space.
 				located here through iotable_init().
 				VMALLOC_START is based upon the value
 				of the high_memory variable, and VMALLOC_END
-				is equal to 0xff000000.
+				is equal to 0xff800000.
 
 PAGE_OFFSET	high_memory-1	Kernel direct-mapped RAM region.
 				This maps the platforms RAM, and typically
diff --git a/arch/arm/include/asm/pgtable.h b/arch/arm/include/asm/pgtable.h
index f40354198b..348caabb76 100644
--- a/arch/arm/include/asm/pgtable.h
+++ b/arch/arm/include/asm/pgtable.h
@@ -43,7 +43,7 @@
  */
 #define VMALLOC_OFFSET		(8*1024*1024)
 #define VMALLOC_START		(((unsigned long)high_memory + VMALLOC_OFFSET) & ~(VMALLOC_OFFSET-1))
-#define VMALLOC_END		0xff000000UL
+#define VMALLOC_END		0xff800000UL
 
 #define LIBRARY_TEXT_START	0x0c000000
 

[PATCH] ARM: fix bug which lowmem size is limited to 760MB

[Nicolas Pitre]

On Mon, 7 Sep 2015, Arnd Bergmann wrote:

> On Thursday 03 September 2015 21:24:00 Nicolas Pitre wrote:
> > If 768MB targets were common place then it could be worth changing the 
> > default vmalloc size to accommodate this memory size and testing all the 
> > other targets to make sure no regressions are introduced.  But given it 
> > is easy to change the default via the kernel cmdline, and that you lose 
> > only 8 MB otherwise, I don't think it is worth the trouble and/or the 
> > risk.
> 
> Agreed.

Well... I think there is a better solution.

Instead of shrinking the vmalloc size, we should instead move 
VMALLOC_END and keep the vmalloc size unchanged.  That also makes for 
nicer address alignment in a subsequent CONFIG_VMSPLIT_3G_OPT patch.

----- >8
ARM: move VMALLOC_END up from 0xff000000 to 0xff800000

There is a 12MB unused region in our memory map between the vmalloc and
fixmap areas. This became unused with commit e9da6e9905e6, confirmed with
commit 64d3b6a3f480.

We also have a 8MB guard area before the vmalloc area.  With the default
240MB vmalloc area size, that puts the end of low memory at 0xef800000
which is unfortunate for 768MB machines where 8MB of RAM is lost to
himem.

Let's move VMALLOC_END to 0xff800000 so the guard area won't chop the
top of the 768MB lomem area while keeping the default vmalloc area size
unchanged and also preserving a gap between the vmalloc and fixmap
areas.

Signed-off-by: Nicolas Pitre <nico@linaro.org>

diff --git a/Documentation/arm/memory.txt b/Documentation/arm/memory.txt
index 4178ebda6e..546a39048e 100644
--- a/Documentation/arm/memory.txt
+++ b/Documentation/arm/memory.txt
@@ -54,7 +54,7 @@ VMALLOC_START	VMALLOC_END-1	vmalloc() / ioremap() space.
 				located here through iotable_init().
 				VMALLOC_START is based upon the value
 				of the high_memory variable, and VMALLOC_END
-				is equal to 0xff000000.
+				is equal to 0xff800000.
 
 PAGE_OFFSET	high_memory-1	Kernel direct-mapped RAM region.
 				This maps the platforms RAM, and typically
diff --git a/arch/arm/include/asm/pgtable.h b/arch/arm/include/asm/pgtable.h
index f40354198b..348caabb76 100644
--- a/arch/arm/include/asm/pgtable.h
+++ b/arch/arm/include/asm/pgtable.h
@@ -43,7 +43,7 @@
  */
 #define VMALLOC_OFFSET		(8*1024*1024)
 #define VMALLOC_START		(((unsigned long)high_memory + VMALLOC_OFFSET) & ~(VMALLOC_OFFSET-1))
-#define VMALLOC_END		0xff000000UL
+#define VMALLOC_END		0xff800000UL
 
 #define LIBRARY_TEXT_START	0x0c000000
 

Re: [PATCH] ARM: fix bug which lowmem size is limited to 760MB

[Russell King - ARM Linux]

On Mon, Sep 07, 2015 at 03:40:36PM -0400, Nicolas Pitre wrote:
> On Mon, 7 Sep 2015, Arnd Bergmann wrote:
> 
> > On Thursday 03 September 2015 21:24:00 Nicolas Pitre wrote:
> > > If 768MB targets were common place then it could be worth changing the 
> > > default vmalloc size to accommodate this memory size and testing all the 
> > > other targets to make sure no regressions are introduced.  But given it 
> > > is easy to change the default via the kernel cmdline, and that you lose 
> > > only 8 MB otherwise, I don't think it is worth the trouble and/or the 
> > > risk.
> > 
> > Agreed.
> 
> Well... I think there is a better solution.

Doesn't this clash with things like:

#define UNCACHEABLE_ADDR        0xff000000      /* IRQ_STAT */

?

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH] ARM: fix bug which lowmem size is limited to 760MB

[Russell King - ARM Linux]

On Mon, Sep 07, 2015 at 03:40:36PM -0400, Nicolas Pitre wrote:
> On Mon, 7 Sep 2015, Arnd Bergmann wrote:
> 
> > On Thursday 03 September 2015 21:24:00 Nicolas Pitre wrote:
> > > If 768MB targets were common place then it could be worth changing the 
> > > default vmalloc size to accommodate this memory size and testing all the 
> > > other targets to make sure no regressions are introduced.  But given it 
> > > is easy to change the default via the kernel cmdline, and that you lose 
> > > only 8 MB otherwise, I don't think it is worth the trouble and/or the 
> > > risk.
> > 
> > Agreed.
> 
> Well... I think there is a better solution.

Doesn't this clash with things like:

#define UNCACHEABLE_ADDR        0xff000000      /* IRQ_STAT */

?

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH] ARM: fix bug which lowmem size is limited to 760MB

[Nicolas Pitre]

On Tue, 8 Sep 2015, Russell King - ARM Linux wrote:

> On Mon, Sep 07, 2015 at 03:40:36PM -0400, Nicolas Pitre wrote:
> > On Mon, 7 Sep 2015, Arnd Bergmann wrote:
> > 
> > > On Thursday 03 September 2015 21:24:00 Nicolas Pitre wrote:
> > > > If 768MB targets were common place then it could be worth changing the 
> > > > default vmalloc size to accommodate this memory size and testing all the 
> > > > other targets to make sure no regressions are introduced.  But given it 
> > > > is easy to change the default via the kernel cmdline, and that you lose 
> > > > only 8 MB otherwise, I don't think it is worth the trouble and/or the 
> > > > risk.
> > > 
> > > Agreed.
> > 
> > Well... I think there is a better solution.
> 
> Doesn't this clash with things like:
> 
> #define UNCACHEABLE_ADDR        0xff000000      /* IRQ_STAT */
> 
> ?

It looks like the move might actually "fix" it.  That UNCACHEABLE_ADDR 
is mapped with:

static struct map_desc ebsa110_io_desc[] __initdata = {
        /*
         * sparse external-decode ISAIO space
         */
        {       /* IRQ_STAT/IRQ_MCLR */
                .virtual        = (unsigned long)IRQ_STAT,
                .pfn            = __phys_to_pfn(TRICK4_PHYS),
                .length         = TRICK4_SIZE,
                .type           = MT_DEVICE
        },
[...]
};

This is passed to iotable_init(), then to create_mapping(). There you 
have:

        if ((md->type == MT_DEVICE || md->type == MT_ROM) &&
            md->virtual >= PAGE_OFFSET &&
            (md->virtual < VMALLOC_START || md->virtual >= VMALLOC_END)) {
                pr_warn("BUG: mapping for 0x%08llx at 0x%08lx out of vmalloc space\n",
                        (long long)__pfn_to_phys((u64)md->pfn), md->virtual);
        }

So you must have hit the above warning somehow. Incidentally, this 
IRQ_STAT entry is the only one that happened to be outside the vmalloc 
area. By moving VMALLOC_END from 0xff000000 to 0xff800000 the warning 
will be gone.


Nicolas

[PATCH] ARM: fix bug which lowmem size is limited to 760MB

[Nicolas Pitre]

On Tue, 8 Sep 2015, Russell King - ARM Linux wrote:

> On Mon, Sep 07, 2015 at 03:40:36PM -0400, Nicolas Pitre wrote:
> > On Mon, 7 Sep 2015, Arnd Bergmann wrote:
> > 
> > > On Thursday 03 September 2015 21:24:00 Nicolas Pitre wrote:
> > > > If 768MB targets were common place then it could be worth changing the 
> > > > default vmalloc size to accommodate this memory size and testing all the 
> > > > other targets to make sure no regressions are introduced.  But given it 
> > > > is easy to change the default via the kernel cmdline, and that you lose 
> > > > only 8 MB otherwise, I don't think it is worth the trouble and/or the 
> > > > risk.
> > > 
> > > Agreed.
> > 
> > Well... I think there is a better solution.
> 
> Doesn't this clash with things like:
> 
> #define UNCACHEABLE_ADDR        0xff000000      /* IRQ_STAT */
> 
> ?

It looks like the move might actually "fix" it.  That UNCACHEABLE_ADDR 
is mapped with:

static struct map_desc ebsa110_io_desc[] __initdata = {
        /*
         * sparse external-decode ISAIO space
         */
        {       /* IRQ_STAT/IRQ_MCLR */
                .virtual        = (unsigned long)IRQ_STAT,
                .pfn            = __phys_to_pfn(TRICK4_PHYS),
                .length         = TRICK4_SIZE,
                .type           = MT_DEVICE
        },
[...]
};

This is passed to iotable_init(), then to create_mapping(). There you 
have:

        if ((md->type == MT_DEVICE || md->type == MT_ROM) &&
            md->virtual >= PAGE_OFFSET &&
            (md->virtual < VMALLOC_START || md->virtual >= VMALLOC_END)) {
                pr_warn("BUG: mapping for 0x%08llx at 0x%08lx out of vmalloc space\n",
                        (long long)__pfn_to_phys((u64)md->pfn), md->virtual);
        }

So you must have hit the above warning somehow. Incidentally, this 
IRQ_STAT entry is the only one that happened to be outside the vmalloc 
area. By moving VMALLOC_END from 0xff000000 to 0xff800000 the warning 
will be gone.


Nicolas

Re: [PATCH] ARM: fix bug which lowmem size is limited to 760MB

[Russell King - ARM Linux]

On Mon, Sep 07, 2015 at 10:01:41PM -0400, Nicolas Pitre wrote:
> On Tue, 8 Sep 2015, Russell King - ARM Linux wrote:
> 
> > On Mon, Sep 07, 2015 at 03:40:36PM -0400, Nicolas Pitre wrote:
> > > On Mon, 7 Sep 2015, Arnd Bergmann wrote:
> > > 
> > > > On Thursday 03 September 2015 21:24:00 Nicolas Pitre wrote:
> > > > > If 768MB targets were common place then it could be worth changing the 
> > > > > default vmalloc size to accommodate this memory size and testing all the 
> > > > > other targets to make sure no regressions are introduced.  But given it 
> > > > > is easy to change the default via the kernel cmdline, and that you lose 
> > > > > only 8 MB otherwise, I don't think it is worth the trouble and/or the 
> > > > > risk.
> > > > 
> > > > Agreed.
> > > 
> > > Well... I think there is a better solution.
> > 
> > Doesn't this clash with things like:
> > 
> > #define UNCACHEABLE_ADDR        0xff000000      /* IRQ_STAT */
> > 
> > ?
> 
> It looks like the move might actually "fix" it.  That UNCACHEABLE_ADDR 
> is mapped with:
> 
> static struct map_desc ebsa110_io_desc[] __initdata = {
>         /*
>          * sparse external-decode ISAIO space
>          */
>         {       /* IRQ_STAT/IRQ_MCLR */
>                 .virtual        = (unsigned long)IRQ_STAT,
>                 .pfn            = __phys_to_pfn(TRICK4_PHYS),
>                 .length         = TRICK4_SIZE,
>                 .type           = MT_DEVICE
>         },
> [...]
> };
> 
> This is passed to iotable_init(), then to create_mapping(). There you 
> have:
> 
>         if ((md->type == MT_DEVICE || md->type == MT_ROM) &&
>             md->virtual >= PAGE_OFFSET &&
>             (md->virtual < VMALLOC_START || md->virtual >= VMALLOC_END)) {
>                 pr_warn("BUG: mapping for 0x%08llx at 0x%08lx out of vmalloc space\n",
>                         (long long)__pfn_to_phys((u64)md->pfn), md->virtual);
>         }
> 
> So you must have hit the above warning somehow. Incidentally, this 
> IRQ_STAT entry is the only one that happened to be outside the vmalloc 
> area. By moving VMALLOC_END from 0xff000000 to 0xff800000 the warning 
> will be gone.

No, there are other legacy platforms which have mappings above that.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH] ARM: fix bug which lowmem size is limited to 760MB

[Russell King - ARM Linux]

On Mon, Sep 07, 2015 at 10:01:41PM -0400, Nicolas Pitre wrote:
> On Tue, 8 Sep 2015, Russell King - ARM Linux wrote:
> 
> > On Mon, Sep 07, 2015 at 03:40:36PM -0400, Nicolas Pitre wrote:
> > > On Mon, 7 Sep 2015, Arnd Bergmann wrote:
> > > 
> > > > On Thursday 03 September 2015 21:24:00 Nicolas Pitre wrote:
> > > > > If 768MB targets were common place then it could be worth changing the 
> > > > > default vmalloc size to accommodate this memory size and testing all the 
> > > > > other targets to make sure no regressions are introduced.  But given it 
> > > > > is easy to change the default via the kernel cmdline, and that you lose 
> > > > > only 8 MB otherwise, I don't think it is worth the trouble and/or the 
> > > > > risk.
> > > > 
> > > > Agreed.
> > > 
> > > Well... I think there is a better solution.
> > 
> > Doesn't this clash with things like:
> > 
> > #define UNCACHEABLE_ADDR        0xff000000      /* IRQ_STAT */
> > 
> > ?
> 
> It looks like the move might actually "fix" it.  That UNCACHEABLE_ADDR 
> is mapped with:
> 
> static struct map_desc ebsa110_io_desc[] __initdata = {
>         /*
>          * sparse external-decode ISAIO space
>          */
>         {       /* IRQ_STAT/IRQ_MCLR */
>                 .virtual        = (unsigned long)IRQ_STAT,
>                 .pfn            = __phys_to_pfn(TRICK4_PHYS),
>                 .length         = TRICK4_SIZE,
>                 .type           = MT_DEVICE
>         },
> [...]
> };
> 
> This is passed to iotable_init(), then to create_mapping(). There you 
> have:
> 
>         if ((md->type == MT_DEVICE || md->type == MT_ROM) &&
>             md->virtual >= PAGE_OFFSET &&
>             (md->virtual < VMALLOC_START || md->virtual >= VMALLOC_END)) {
>                 pr_warn("BUG: mapping for 0x%08llx at 0x%08lx out of vmalloc space\n",
>                         (long long)__pfn_to_phys((u64)md->pfn), md->virtual);
>         }
> 
> So you must have hit the above warning somehow. Incidentally, this 
> IRQ_STAT entry is the only one that happened to be outside the vmalloc 
> area. By moving VMALLOC_END from 0xff000000 to 0xff800000 the warning 
> will be gone.

No, there are other legacy platforms which have mappings above that.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH] ARM: fix bug which lowmem size is limited to 760MB

[Nicolas Pitre]

On Tue, 8 Sep 2015, Russell King - ARM Linux wrote:

> On Mon, Sep 07, 2015 at 10:01:41PM -0400, Nicolas Pitre wrote:
> 
[...]
> > This is passed to iotable_init(), then to create_mapping(). There you 
> > have:
> > 
> >         if ((md->type == MT_DEVICE || md->type == MT_ROM) &&
> >             md->virtual >= PAGE_OFFSET &&
> >             (md->virtual < VMALLOC_START || md->virtual >= VMALLOC_END)) {
> >                 pr_warn("BUG: mapping for 0x%08llx at 0x%08lx out of vmalloc space\n",
> >                         (long long)__pfn_to_phys((u64)md->pfn), md->virtual);
> >         }
> > 
> > So you must have hit the above warning somehow. Incidentally, this 
> > IRQ_STAT entry is the only one that happened to be outside the vmalloc 
> > area. By moving VMALLOC_END from 0xff000000 to 0xff800000 the warning 
> > will be gone.
> 
> No, there are other legacy platforms which have mappings above that.

... for that particular map_desc array instance I mean.

WRT other legacy platforms: if the above warning didn't bother anyone 
for the last 4 years, then it won't be such an issue either if the 
current proposal doesn't solve them all.  That's not the primary purpose 
of this change anyway. In those cases, the appropriate fix, like it is 
today, should consist in some adjustment of those virtual addresses to 
bring them inside the vmalloc area.

Your original concern was whether extending the vmalloc area upward 
would clash with something else, and the short answer is no.


Nicolas

[PATCH] ARM: fix bug which lowmem size is limited to 760MB

[Nicolas Pitre]

On Tue, 8 Sep 2015, Russell King - ARM Linux wrote:

> On Mon, Sep 07, 2015 at 10:01:41PM -0400, Nicolas Pitre wrote:
> 
[...]
> > This is passed to iotable_init(), then to create_mapping(). There you 
> > have:
> > 
> >         if ((md->type == MT_DEVICE || md->type == MT_ROM) &&
> >             md->virtual >= PAGE_OFFSET &&
> >             (md->virtual < VMALLOC_START || md->virtual >= VMALLOC_END)) {
> >                 pr_warn("BUG: mapping for 0x%08llx at 0x%08lx out of vmalloc space\n",
> >                         (long long)__pfn_to_phys((u64)md->pfn), md->virtual);
> >         }
> > 
> > So you must have hit the above warning somehow. Incidentally, this 
> > IRQ_STAT entry is the only one that happened to be outside the vmalloc 
> > area. By moving VMALLOC_END from 0xff000000 to 0xff800000 the warning 
> > will be gone.
> 
> No, there are other legacy platforms which have mappings above that.

... for that particular map_desc array instance I mean.

WRT other legacy platforms: if the above warning didn't bother anyone 
for the last 4 years, then it won't be such an issue either if the 
current proposal doesn't solve them all.  That's not the primary purpose 
of this change anyway. In those cases, the appropriate fix, like it is 
today, should consist in some adjustment of those virtual addresses to 
bring them inside the vmalloc area.

Your original concern was whether extending the vmalloc area upward 
would clash with something else, and the short answer is no.


Nicolas