From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Grygorii Strashko <grygorii.strashko@ti.com>
Cc: Nicolas Pitre <nicolas.pitre@linaro.org>,
Andrew Lunn <andrew@lunn.ch>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>,
Grant Likely <grant.likely@secretlab.ca>,
linux-mm@kvack.org, Daniel Walker <dwalker@fifo99.com>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Kukjin Kim <kgene.kim@samsung.com>,
David Brown <davidb@codeaurora.org>,
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>,
Laura Abbott <lauraa@codeaurora.org>,
Jason Cooper <jason@lakedaemon.net>,
linux-arm-msm@vger.kernel.org,
Haojian Zhuang <haojian.zhuang@gmail.com>,
Leif Lindholm <leif.lindholm@linaro.org>,
Ben Dooks <ben-linux@fluff.org>,
linux-arm-kernel@lists.infradead.org,
Courtney Cavin <courtney.cavin@sonymobile.com>,
Eric Miao <eric.y.miao@gmail.com>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
linux-kernel@vger.kernel.org,
Santosh Shilimkar <santosh.shilimkar@ti.com>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCHv4 2/2] arm: Get rid of meminfo
Date: Wed, 12 Mar 2014 14:05:22 +0000 [thread overview]
Message-ID: <20140312140522.GI21483@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <20140312133806.GH21483@n2100.arm.linux.org.uk>
On Wed, Mar 12, 2014 at 01:38:06PM +0000, Russell King - ARM Linux wrote:
> Try booting a machine with 2G of RAM with page offset set to 3GB and
> highmem enabled - it will fail as per the above.
BTW, simple way to test this on any ARM platform:
Build with PAGE_OFFSET=3GB and highmem enabled. Pass vmalloc=1G on the
kernel command line to force maximal vmalloc region (which should push
lowmem down to the minimum of 32MB.) The remainder will be highmem.
Now, with Laura's patch applied, some platforms do boot but the result
is rather odd:
vmalloc area is too big, limiting to 976MB
So, the vmalloc=1G has done the right thing here, but:
Memory: 507404K/523264K available (3839K kernel code, 230K rwdata, 1388K rodata, 211K init, 5266K bss, 15860K reserved, 0K highmem)
Virtual kernel memory layout:
vector : 0xffff0000 - 0xffff1000 ( 4 kB)
fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
vmalloc : 0xe0800000 - 0xff000000 ( 488 MB)
lowmem : 0xc0000000 - 0xe0000000 ( 512 MB)
pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB)
modules : 0xbf000000 - 0xbfe00000 ( 14 MB)
.text : 0xc0008000 - 0xc0522f34 (5228 kB)
.init : 0xc0523000 - 0xc0557fc0 ( 212 kB)
.data : 0xc0558000 - 0xc0591980 ( 231 kB)
.bss : 0xc0591988 - 0xc0ab6220 (5267 kB)
something has overriden it, and we end up with no highmem. Without
Laura's patch, it all behaves correctly:
vmalloc area is too big, limiting to 976MB
...
Memory: 507932K/523264K available (3839K kernel code, 230K rwdata, 1388K rodata, 211K init, 5266K bss, 15332K reserved, 490496K highmem)
Virtual kernel memory layout:
vector : 0xffff0000 - 0xffff1000 ( 4 kB)
fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
vmalloc : 0xc2800000 - 0xff000000 ( 968 MB)
lowmem : 0xc0000000 - 0xc2000000 ( 32 MB)
pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB)
modules : 0xbf000000 - 0xbfe00000 ( 14 MB)
.text : 0xc0008000 - 0xc0522f34 (5228 kB)
.init : 0xc0523000 - 0xc0557fc0 ( 212 kB)
.data : 0xc0558000 - 0xc0591980 ( 231 kB)
.bss : 0xc0591988 - 0xc0ab6260 (5267 kB)
So... the more I look at the boot results from last night's autobuild,
the more stuff appears to be broken with this meminfo removal.
Therefore, I have to wonder what kind of testing was done with these
patches - I suspect the test consisted of "does it boot" without looking
at any of the details about what memory was where.
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2014-03-12 14:05 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-18 22:15 [PATCHv4 0/2] Remove ARM meminfo Laura Abbott
2014-02-18 22:15 ` [PATCHv4 1/2] mm/memblock: add memblock_get_current_limit Laura Abbott
2014-02-18 22:54 ` Nicolas Pitre
2014-02-18 22:15 ` [PATCHv4 2/2] arm: Get rid of meminfo Laura Abbott
2014-02-18 23:07 ` Russell King - ARM Linux
2014-02-18 23:49 ` Nicolas Pitre
2014-02-18 23:47 ` Nicolas Pitre
2014-03-12 8:54 ` Russell King - ARM Linux
2014-03-12 13:09 ` Grygorii Strashko
2014-03-12 13:38 ` Russell King - ARM Linux
2014-03-12 14:05 ` Russell King - ARM Linux [this message]
2014-03-12 16:08 ` Grygorii Strashko
2014-03-19 18:23 ` Laura Abbott
2014-03-12 14:44 ` 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=20140312140522.GI21483@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=akpm@linux-foundation.org \
--cc=andrew@lunn.ch \
--cc=ard.biesheuvel@linaro.org \
--cc=ben-linux@fluff.org \
--cc=catalin.marinas@arm.com \
--cc=courtney.cavin@sonymobile.com \
--cc=davidb@codeaurora.org \
--cc=dwalker@fifo99.com \
--cc=eric.y.miao@gmail.com \
--cc=grant.likely@secretlab.ca \
--cc=grygorii.strashko@ti.com \
--cc=haojian.zhuang@gmail.com \
--cc=jason@lakedaemon.net \
--cc=kgene.kim@samsung.com \
--cc=lauraa@codeaurora.org \
--cc=leif.lindholm@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=m.szyprowski@samsung.com \
--cc=nicolas.pitre@linaro.org \
--cc=santosh.shilimkar@ti.com \
--cc=sebastian.hesselbarth@gmail.com \
--cc=will.deacon@arm.com \
/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).