Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1218006 > unrolled thread

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

Started byYongtaek Lee <ytk.lee@samsung.com>
First post2015-09-03 04:30 +0200
Last post2015-09-03 11:10 +0200
Articles 10 — 4 participants

Back to article view | Back to linux.kernel

Contents

  [PATCH] ARM: fix bug which VMALLOC_START is lowwer than 0xf0000000 Yongtaek Lee <ytk.lee@samsung.com> - 2015-09-03 04:30 +0200
    [PATCH] ARM: fix bug which lowmem size is limited to 760MB Yongtaek Lee <ytk.lee@samsung.com> - 2015-09-03 07:20 +0200
    Re: [PATCH] ARM: fix bug which VMALLOC_START is lowwer than  0xf0000000 Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-09-03 10:10 +0200
      Re: Re: [PATCH] ARM: fix bug which VMALLOC_START is lowwer than  0xf0000000 Yongtaek Lee <ytk.lee@samsung.com> - 2015-09-03 10:30 +0200
        Re: Re: [PATCH] ARM: fix bug which VMALLOC_START is lowwer than  0xf0000000 Lucas Stach <l.stach@pengutronix.de> - 2015-09-03 10:40 +0200
          Re: Re: Re: [PATCH] ARM: fix bug which VMALLOC_START is lowwer than  0xf0000000 Yongtaek Lee <ytk.lee@samsung.com> - 2015-09-03 10:50 +0200
            Re: Re: Re: [PATCH] ARM: fix bug which VMALLOC_START is lowwer than  0xf0000000 Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-09-03 11:20 +0200
              [PATCH] ARM: fix bug which lowmem size is limited to 760MB Yongtaek Lee <ytk.lee@samsung.com> - 2015-09-03 12:40 +0200
                Re: [PATCH] ARM: fix bug which lowmem size is limited to 760MB Nicolas Pitre <nicolas.pitre@linaro.org> - 2015-09-04 03:30 +0200
          Re: Re: [PATCH] ARM: fix bug which VMALLOC_START is lowwer than  0xf0000000 Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-09-03 11:10 +0200

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

FromYongtaek Lee <ytk.lee@samsung.com>
Date2015-09-03 04:30 +0200
Subject[PATCH] ARM: fix bug which VMALLOC_START is lowwer than 0xf0000000
Message-ID<q4srL-6VH-1@gated-at.bofh.it>
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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

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

FromYongtaek Lee <ytk.lee@samsung.com>
Date2015-09-03 07:20 +0200
Subject[PATCH] ARM: fix bug which lowmem size is limited to 760MB
Message-ID<q4v6j-2kz-25@gated-at.bofh.it>
In reply to#1218006
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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

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

FromRussell King - ARM Linux <linux@arm.linux.org.uk>
Date2015-09-03 10:10 +0200
SubjectRe: [PATCH] ARM: fix bug which VMALLOC_START is lowwer than 0xf0000000
Message-ID<q4xKN-69T-3@gated-at.bofh.it>
In reply to#1218006
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

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

FromYongtaek Lee <ytk.lee@samsung.com>
Date2015-09-03 10:30 +0200
SubjectRe: Re: [PATCH] ARM: fix bug which VMALLOC_START is lowwer than 0xf0000000
Message-ID<q4y4a-6wl-17@gated-at.bofh.it>
In reply to#1218090
> 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. 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

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

FromLucas Stach <l.stach@pengutronix.de>
Date2015-09-03 10:40 +0200
SubjectRe: Re: [PATCH] ARM: fix bug which VMALLOC_START is lowwer than 0xf0000000
Message-ID<q4ydP-6Hz-1@gated-at.bofh.it>
In reply to#1218099
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/  |

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

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

FromYongtaek Lee <ytk.lee@samsung.com>
Date2015-09-03 10:50 +0200
SubjectRe: Re: Re: [PATCH] ARM: fix bug which VMALLOC_START is lowwer than 0xf0000000
Message-ID<q4ynv-6T4-1@gated-at.bofh.it>
In reply to#1218100
> 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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

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

FromRussell King - ARM Linux <linux@arm.linux.org.uk>
Date2015-09-03 11:20 +0200
SubjectRe: Re: Re: [PATCH] ARM: fix bug which VMALLOC_START is lowwer than 0xf0000000
Message-ID<q4yQy-7Gl-29@gated-at.bofh.it>
In reply to#1218103
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

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

FromYongtaek Lee <ytk.lee@samsung.com>
Date2015-09-03 12:40 +0200
Subject[PATCH] ARM: fix bug which lowmem size is limited to 760MB
Message-ID<q4A5X-YQ-11@gated-at.bofh.it>
In reply to#1218118
> 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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

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

FromNicolas Pitre <nicolas.pitre@linaro.org>
Date2015-09-04 03:30 +0200
SubjectRe: [PATCH] ARM: fix bug which lowmem size is limited to 760MB
Message-ID<q4NZf-3Zz-11@gated-at.bofh.it>
In reply to#1218142
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

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

FromRussell King - ARM Linux <linux@arm.linux.org.uk>
Date2015-09-03 11:10 +0200
SubjectRe: Re: [PATCH] ARM: fix bug which VMALLOC_START is lowwer than 0xf0000000
Message-ID<q4yGS-7v1-11@gated-at.bofh.it>
In reply to#1218100
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web