linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: f.fainelli@gmail.com (Florian Fainelli)
To: linux-arm-kernel@lists.infradead.org
Subject: vmalloc_reserve with no highmem
Date: Mon, 19 Oct 2015 16:20:05 -0700	[thread overview]
Message-ID: <56257AA5.1030800@gmail.com> (raw)

Hi Russell, Laura,

Setting vmalloc= on the kernel command-line to define the amount of
vmalloc_reserve is not quite working when you have no highmem, as is the
case of one my boards which has 512MB or 256M populated on a first bank
at PA 0x0.

What happens in that case is that, despite setting vmalloc_reserve,
therefore bumping up vmalloc_min to a higher address than high_memory,
which is assigned __va(arm_lowmem_limit), we end-up with VMALLOC_START
at high_memory + VMALLOC_OFFSET, which yields the amount of physical
memory (start at PA 0x0 in my case) - VMALLOC_OFFSET.

The maths look like this for this particular board (512MB)

high_memory = 0x20000000 + PAGE_OFFSET = 0x20000000 + 0xC0000000 =
0xE0000000
vmalloc_min = 0xFF00000 - (248 * 1024 * 1024) = 0xEF800000

so we end-up with VMALLOC_START = high_memory + VMALLOC_OFFSET =
0xE0000000 + 8 * 1024* 1024 = 0xE0800000

in sanity_check_meminfo(), high_memory is unconditionally assigned with
arm_lowmem_limit's VA.

The following quick and dirty patch seems to do it for me, but I am not
confident this is remotely the correct approach here:

diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 14428d2..e196ea4 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -1196,7 +1211,14 @@ void __init sanity_check_meminfo(void)
        }
 #endif
        meminfo.nr_banks = j;
-       high_memory = __va(arm_lowmem_limit - 1) + 1;
+
+       if (vmalloc_limit > arm_lowmem_limit)
+               high_memory = vmalloc_min - VMALLOC_OFFSET;
+       else
+               high_memory = __va(arm_lowmem_limit - 1) + 1;
+
+       pr_info("%s: high_memory: 0x%p, arm_lowmem_limit: 0x%llx\n",
+               __func__, high_memory, arm_lowmem_limit);

BTW, even when there is highmem available, setting vmalloc= on the
command-line is off by VMALLOC_OFFSET, the way early_vmalloc() computes
things, is that intended?

Thanks!
-- 
Florian

             reply	other threads:[~2015-10-19 23:20 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-19 23:20 Florian Fainelli [this message]
2015-10-20 18:52 ` vmalloc_reserve with no highmem Laura Abbott
2015-10-20 19:17   ` Florian Fainelli
2015-10-20 19:25     ` Russell King - ARM Linux
2015-10-20 19:32       ` Florian Fainelli
2015-10-20 19:40         ` Russell King - ARM Linux
2015-10-25  3:18           ` Gregory Fong
2015-10-20 19:27     ` Laura Abbott

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=56257AA5.1030800@gmail.com \
    --to=f.fainelli@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.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;
as well as URLs for NNTP newsgroup(s).