From: u.kleine-koenig@pengutronix.de (Uwe Kleine-König)
To: linux-arm-kernel@lists.infradead.org
Subject: does non-continuous RAM means I need to select the sparse memory model?
Date: Thu, 1 Dec 2011 21:55:37 +0100 [thread overview]
Message-ID: <20111201205537.GO26618@pengutronix.de> (raw)
In-Reply-To: <20111201182852.GC9581@n2100.arm.linux.org.uk>
On Thu, Dec 01, 2011 at 06:28:52PM +0000, Russell King - ARM Linux wrote:
> On Tue, Nov 29, 2011 at 09:30:10PM +0100, Uwe Kleine-K?nig wrote:
> > I'm currently working on a new arch port and my current machine has RAM
> > at 0x10000000 and 0x80000000. So there is a big hole between the two
> > banks. When selecting the sparse memory model it works, but when
> > selecting flat the machine runs into a BUG in mark_bootmem() called by
> > free_unused_memmap() to free the space between the two banks.
>
> Well, it looks like you have the answer in your latest email:
>
> > Apart from that it seems I cannot use flatmem as is on my machine. It
> > has only 128kiB at 0x10000000 + 1MiB at 0x80000000 and needs 14MiB to hold the
> > table of "struct page"s.
>
> Which shows that there's no possible way to use flatmem in this platform.
>
> Now, to use sparsemem with this, sparsemem people will tell you that
> each sparsemem section must be fully populated. So, as your minimum
> memory size is 128kiB, your sparsemem section size must be 128kiB.
> This makes SECTION_SIZE_BITS be 17.
>
> You need to span to 0x80000000+, which means you need MAX_PHYSMEM_BITS
> to be 32.
>
> These two together means you're in for having an array of 2^(32 - 17) =
> 32768 pointers to struct section for starters. That takes 128kiB.
> Now add in the struct page structures, which for 128kiB of memory will
> be 1kiB. Now add 9 struct section's as well...
>
> What I'm pointing out is that in the scenario you appear to have, trying
> to use the small pool of memory which is soo dislocated from the rest of
> memory is a waste of effort. Adding it to the pool means that you require
> more memory for the management data structures than you gain from adding
> it to the system. The net benefit from trying to use it is actually
> negative.
>
> So, forget that the 128kiB chunk of memory exists - at that size and
> distance from the rest of memory its really not worth bothering with.
many thanks for your description. I'll go with flatmem skipping the
128kiB bank now.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
prev parent reply other threads:[~2011-12-01 20:55 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-29 20:30 does non-continuous RAM means I need to select the sparse memory model? Uwe Kleine-König
2011-11-30 0:39 ` Fabio Estevam
2011-11-30 7:32 ` Uwe Kleine-König
2011-12-01 10:57 ` flatmem broken for nommu? [Was: Re: does non-continuous RAM means I need to select the sparse memory model?] Uwe Kleine-König
2011-12-01 15:39 ` Uwe Kleine-König
2011-12-01 16:10 ` Stefan Hellermann
2011-12-01 20:18 ` Uwe Kleine-König
2011-12-01 18:28 ` does non-continuous RAM means I need to select the sparse memory model? Russell King - ARM Linux
2011-12-01 20:55 ` Uwe Kleine-König [this message]
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=20111201205537.GO26618@pengutronix.de \
--to=u.kleine-koenig@pengutronix.de \
--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).