linux-mips
[Top] [All Lists]

Re: [PATCH] sparsemem fix

To: kreese@caviumnetworks.com
Subject: Re: [PATCH] sparsemem fix
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Date: Wed, 05 Jul 2006 10:30:13 +0900 (JST)
Cc: linux-mips@linux-mips.org, ralf@linux-mips.org
In-reply-to: <44AA9F67.3090309@caviumnetworks.com>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20060705.012244.96686002.anemo@mba.ocn.ne.jp> <44AA9F67.3090309@caviumnetworks.com>
Sender: linux-mips-bounce@linux-mips.org
On Tue, 04 Jul 2006 10:03:35 -0700, Chad Reese <kreese@caviumnetworks.com> 
wrote:
> I believe Ralf committed a cleaned up version of the patch I created 
> 5/23/2006. It called memory_present() after the first bootmap memory was 
> created. I've been using this and dynamic sparsemem on Mips64 for a 
> while now.

It is not enough.  If you want to use SPARSEMEM_EXTREME, do not call
memory_present() _before_ reserve_bootmem().

For SPARSEMEM_EXTREME, memory_present() try to allocate bootmem, but
first area of bootmem must be reserved for bootmap before any
allocation.

The alloc_bootmem_node try to allocate upper (>16MB) page first, then
try lower page.  So if the first memory area was smaller then 16MB
SPARSEMEM_EXTREME would not work.

Also, SPARSEMEM_STATIC will be a bit faster then SPARSEMEM_EXTREME.
The mm/Kconfig warns about mem_section[] size, but static
mem_section[] size is just 1KB for MIPS.  No problem.  :-)

---
Atsushi Nemoto

<Prev in Thread] Current Thread [Next in Thread>