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
WARNING: multiple messages have this Message-ID (diff)
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
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2008-05-07 12:29 UTC|newest]
Thread overview: 24+ 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 ` Johannes Weiner
2008-05-05 9:59 ` [rfc][patch 1/3] mm: Define NR_NODE_MEMBLKS unconditionally Johannes Weiner
2008-05-05 9:59 ` 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 ` Johannes Weiner
2008-05-05 9:59 ` [rfc][patch 3/3] x86: Use bootmem2 on x86_32 Johannes Weiner
2008-05-05 9:59 ` Johannes Weiner
2008-05-05 11:23 ` [rfc][patch 0/3] bootmem2: a memory block-oriented boot time allocator Johannes Weiner
2008-05-05 11:23 ` Johannes Weiner
2008-05-05 15:23 ` Linus Torvalds
2008-05-05 15:23 ` Linus Torvalds
2008-05-05 16:04 ` Robin Holt
2008-05-05 16:04 ` Robin Holt
2008-05-06 9:00 ` Johannes Weiner
2008-05-06 9:00 ` Johannes Weiner
2008-05-05 18:58 ` Andi Kleen
2008-05-05 18:58 ` Andi Kleen
2008-05-06 8:57 ` Johannes Weiner
2008-05-06 8:57 ` Johannes Weiner
2008-05-07 12:29 ` Johannes Weiner [this message]
2008-05-07 12:29 ` [RFC no patch yet] bootmem2: Another try Johannes Weiner
2008-05-07 14:37 ` Linus Torvalds
2008-05-07 14:37 ` 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 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.