From: grygorii.strashko@ti•com (Grygorii Strashko)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCHv4 2/2] arm: Get rid of meminfo
Date: Wed, 12 Mar 2014 15:09:53 +0200 [thread overview]
Message-ID: <53205CA1.1090502@ti.com> (raw)
In-Reply-To: <20140312085401.GB21483@n2100.arm.linux.org.uk>
Hi Russell,
On 03/12/2014 10:54 AM, Russell King - ARM Linux wrote:
> On Tue, Feb 18, 2014 at 02:15:33PM -0800, Laura Abbott wrote:
>> memblock is now fully integrated into the kernel and is the prefered
>> method for tracking memory. Rather than reinvent the wheel with
>> meminfo, migrate to using memblock directly instead of meminfo as
>> an intermediate.
>>
>> Acked-by: Jason Cooper <jason@lakedaemon•net>
>> Acked-by: Catalin Marinas <catalin.marinas@arm•com>
>> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti•com>
>> Acked-by: Kukjin Kim <kgene.kim@samsung•com>
>> Tested-by: Marek Szyprowski <m.szyprowski@samsung•com>
>> Tested-by: Leif Lindholm <leif.lindholm@linaro•org>
>> Signed-off-by: Laura Abbott <lauraa@codeaurora•org>
>
> Laura,
>
> This patch causes a bunch of platforms to no longer boot - imx6solo with
> 1GB of RAM boots, imx6q with 2GB of RAM doesn't. Versatile Express doesn't.
>
> The early printk messages don't reveal anything too interesting:
>
> Booting Linux on physical CPU 0x0
> Linux version 3.14.0-rc6+ (rmk at rmk-PC.arm.linux.org.uk) (gcc version 4.6.4 (GCC) ) #630 SMP Wed Mar 12 01:13:36 GMT 2014
> CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c53c7d
> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> Machine model: SolidRun Cubox-i Dual/Quad
> cma: CMA: reserved 64 MiB at 8c000000
> Memory policy: Data cache writealloc
> <hang>
>
> vs.
>
> Booting Linux on physical CPU 0x0
> Linux version 3.14.0-rc6+ (rmk at rmk-PC.arm.linux.org.uk) (gcc version 4.6.4 (GCC) ) #631 SMP Wed Mar 12 01:15:37 GMT 2014
> CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c53c7d
> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> Machine model: SolidRun Cubox-i Dual/Quad
> cma: CMA: reserved 64 MiB at 3b800000
> Memory policy: Data cache writealloc
> On node 0 totalpages: 524288
> free_area_init_node: node 0, pgdat c09d0240, node_mem_map ea7d8000
> Normal zone: 1520 pages used for memmap
> Normal zone: 0 pages reserved
> Normal zone: 194560 pages, LIFO batch:31
> HighMem zone: 2576 pages used for memmap
> HighMem zone: 329728 pages, LIFO batch:31
> ...
>
> The only obvious difference is the address of that CMA reservation,
> CMA shouldn't make a difference here - but I suspect that other
> allocations which need to be in lowmem probably aren't.
>
Could it be possible to enable memblock debug by adding "memblock=debug"
in cmdline?
Regards,
-grygorii
next prev parent reply other threads:[~2014-03-12 13:09 UTC|newest]
Thread overview: 12+ 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 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 [this message]
2014-03-12 13:38 ` Russell King - ARM Linux
2014-03-12 14:05 ` Russell King - ARM Linux
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=53205CA1.1090502@ti.com \
--to=grygorii.strashko@ti$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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