mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Yongtaek Lee <ytk.lee@samsung.com>
To: Russell King <linux@arm.linux.org.uk>
Cc: linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	Nicolas Pitre <nicolas.pitre@linaro.org>,
	ytk.lee@samsung.com
Subject: [PATCH] ARM: fix bug which lowmem size is limited to 760MB
Date: Thu, 03 Sep 2015 19:30:33 +0900	[thread overview]
Message-ID: <1441276233-14566-1-git-send-email-ytk.lee@samsung.com> (raw)
In-Reply-To: <20150903091044.GW21084@n2100.arm.linux.org.uk>

> 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.


  reply	other threads:[~2015-09-03 10:30 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-03  2:24 [PATCH] ARM: fix bug which VMALLOC_START is lowwer than 0xf0000000 Yongtaek Lee
2015-09-03  5:11 ` [PATCH] ARM: fix bug which lowmem size is limited to 760MB Yongtaek Lee
2015-09-03  8:00 ` [PATCH] ARM: fix bug which VMALLOC_START is lowwer than 0xf0000000 Russell King - ARM Linux
2015-09-03  8:28   ` Yongtaek Lee
2015-09-03  8:34     ` Lucas Stach
2015-09-03  8:43       ` Yongtaek Lee
2015-09-03  9:10         ` Russell King - ARM Linux
2015-09-03 10:30           ` Yongtaek Lee [this message]
2015-09-04  1:24             ` [PATCH] ARM: fix bug which lowmem size is limited to 760MB Nicolas Pitre
2015-09-07 11:41               ` Arnd Bergmann
2015-09-07 15:34                 ` Nicolas Pitre
2015-09-07 15:45                   ` Arnd Bergmann
2015-09-07 15:49                     ` Nicolas Pitre
2015-09-07 19:40                 ` Nicolas Pitre
2015-09-08  0:10                   ` Russell King - ARM Linux
2015-09-08  2:01                     ` Nicolas Pitre
2015-09-08  8:03                       ` Russell King - ARM Linux
2015-09-08 14:58                         ` Nicolas Pitre
2015-09-03  9:07       ` Re: [PATCH] ARM: fix bug which VMALLOC_START is lowwer than 0xf0000000 Russell King - ARM Linux

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1441276233-14566-1-git-send-email-ytk.lee@samsung.com \
    --to=ytk.lee@samsung.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=nicolas.pitre@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®