public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Johannes Weiner <hannes@saeurebad.de>
To: linux-kernel@vger.kernel.org
Cc: linux-mm@kvack.org, Ingo Molnar <mingo@elte.hu>,
	Andi Kleen <andi@firstfloor.org>,
	Yinghai Lu <yhlu.kernel@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Yasunori Goto <y-goto@jp.fujitsu.com>
Subject: [RFC no patch yet] bootmem2: Another try
Date: Wed, 07 May 2008 14:29:20 +0200	[thread overview]
Message-ID: <87ve1qcn6n.fsf@saeurebad.de> (raw)
In-Reply-To: <20080505095938.326928514@symbol.fehenstaub.lan> (Johannes Weiner's message of "Mon, 05 May 2008 11:59:38 +0200")

Hi,

my idea is now as follows:

Bootmem2 is block-oriented where a block represents a contiguous range
of physical memory.  Every block has a bitmap that keeps track of the
pages on it.

On top of this block interface, bootmem2 implements the node model
where a node can provide one or more memory blocks.

On configurations with multiple blocks per node, the arch code has to
register each block on its own.

free_bootmem and reserve_bootmem require that the requested range is
contiguous but they might go across node boundaries (two blocks on two
nodes can be contiguous).  For example:

node 0: block 0 = 0-2G, block 1 = 4-6G
node 1: block 2 = 2-4G, block 3 = 6-8G

free_bootmem(1.5G, 3G) is valid here, the range spans two nodes and two
blocks but is contiguous.

free_bootmem_node and reserve_bootmem_node are more strict, the ranges
have to be completely within one block of the specified node (two
blocks on one node are never contiguous).

alloc_bootmem_node tries to get memory between goal and limit from a
specific node and falls back to any free memory range on that node on
failure.

alloc_bootmem tries to get memory from between goal and limit and
falls back to any free memory range in the system on failure.

What do you say?

	Hannes

  parent reply	other threads:[~2008-05-07 12:29 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-05  9:59 [rfc][patch 0/3] bootmem2: a memory block-oriented boot time allocator Johannes Weiner
2008-05-05  9:59 ` [rfc][patch 1/3] mm: Define NR_NODE_MEMBLKS unconditionally Johannes Weiner
2008-05-05  9:59 ` [rfc][patch 2/3] mm: bootmem2 - memory block oriented boot time allocator Johannes Weiner
2008-05-05  9:59 ` [rfc][patch 3/3] x86: Use bootmem2 on x86_32 Johannes Weiner
2008-05-05 11:23 ` [rfc][patch 0/3] bootmem2: a memory block-oriented boot time allocator Johannes Weiner
2008-05-05 15:23 ` Linus Torvalds
2008-05-05 16:04   ` Robin Holt
2008-05-06  9:00     ` Johannes Weiner
2008-05-05 18:58 ` Andi Kleen
2008-05-06  8:57   ` Johannes Weiner
2008-05-07 12:29 ` Johannes Weiner [this message]
2008-05-07 14:37   ` [RFC no patch yet] bootmem2: Another try Linus Torvalds

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=87ve1qcn6n.fsf@saeurebad.de \
    --to=hannes@saeurebad.de \
    --cc=akpm@linux-foundation.org \
    --cc=andi@firstfloor.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mingo@elte.hu \
    --cc=torvalds@linux-foundation.org \
    --cc=y-goto@jp.fujitsu.com \
    --cc=yhlu.kernel@gmail.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