All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ralf Baechle <ralf@linux-mips.org>
To: Manuel Lauss <manuel.lauss@googlemail.com>
Cc: Linux-MIPS <linux-mips@linux-mips.org>
Subject: Re: use bootmem in platform code on MIPS
Date: Wed, 28 Apr 2010 16:54:39 +0100	[thread overview]
Message-ID: <20100428155439.GA19468@linux-mips.org> (raw)
In-Reply-To: <k2lf861ec6f1004270514k199cace5wafd6dd269ded8911@mail.gmail.com>

On Tue, Apr 27, 2010 at 02:14:32PM +0200, Manuel Lauss wrote:

> I'd like to use bootmem to reserve large chunks of RAM (at a particular physical
> address; for Au1200 MAE, CIM and framebuffer, and later Au1300 OpenGL block)
> but it seems that it can't be done:  Doing __alloc_bootmem() in
> plat_mem_setup() is
> too early, while an arch_initcall() is too late because by then the
> slab allocator is
> already up and handing out random addresses and/or refusing allocations larger
> than a few MBytes.

The maximum is actually configurable.  CONFIG_FORCE_MAX_ZONEORDER defaults
to 11 which means with 4kB pages you get 8MB maximum allocation - more for
larger pages.

CONFIG_FORCE_MAX_ZONEORDER is a tradeoff though.  A smaller value will give
slightly better performance and safe a bit of memory but I can't really
quantify these numbers - I assume it's a small difference.

It may actually be preferable to never tell the bootmem allocator about the
memory you need for these devices that is bypass the mm code entirely.

> Is there another callback I could use which would allow me to use bootmem (short
> of abusing plat_smp_setup)?
> 
> Would a separate callback like this be an acceptable solution?

Certainly better than using plat_smp_setup which would require enabling
SMP support for no good reason at all.

I know we will eventually have to add another platform hooks to run after
bootmem_init.  The name of plat_mem_setup() already shows what this hook
originally was meant for but it ended up as the everything-and-the-kitchen-
sink hook for platform-specific early initialization.  I just dislike
conditional hooks.  Let's add a call to a new hook function and fix whatever
breaks or think about what other hooks needs there should be.

  Ralf

  reply	other threads:[~2010-04-28 15:54 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-27 12:14 use bootmem in platform code on MIPS Manuel Lauss
2010-04-28 15:54 ` Ralf Baechle [this message]
2010-04-28 16:28   ` Manuel Lauss
2010-04-28 18:59     ` David Daney

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=20100428155439.GA19468@linux-mips.org \
    --to=ralf@linux-mips.org \
    --cc=linux-mips@linux-mips.org \
    --cc=manuel.lauss@googlemail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.