login
Login
/
Register
Search
Search this site:
Forums
News
Blogs
Features
Site
Home
»
Mailing list archives
»
linux-kernel
»
2008
»
May
»
6
Re: [rfc][patch 0/3] bootmem2: a memory block-oriented boot time allocator
view
thread
Previous message: [
thread
] [
date
] [
author
]
Next message: [
thread
] [
date
] [
author
]
[view in full thread]
From: Johannes Weiner
Subject:
Re: [rfc][patch 0/3] bootmem2: a memory block-oriented boot time allocator
Date: Tuesday, May 6, 2008 - 2:00 am
Hi, Robin Holt <holt@sgi.com> writes:
quoted text
> On Mon, May 05, 2008 at 08:23:34AM -0700, Linus Torvalds wrote: >> >> >> On Mon, 5 May 2008, Johannes Weiner wrote: >> > >> > here is a bootmem allocator replacement that uses one bitmap for all >> > available pages and works with a model of contiguous memory blocks >> > that reside on nodes instead of nodes only as the current allocator >> > does. >> >> Won't this have problems with huge non-contiguous areas? >> >> Some setups have traditionally had node memory separated in physical space >> by the high bits of the memory address, and using a single bitmap for such >> things would potentially be basically impossible - even with a single bit >> per page, the "span" of possible pages is potentially just too high, even >> if the nodes themselves don't have tons of memory, because the memory is >> just very spread out - and allocating the initial bitmap may not work >> reliably. >> >> Now, admittedly I don't know if we even support that kind of thing or if >> people really do things that way any more, so maybe it's not an issue. > > SGI sn2 architecture does. Each DIMM bank is allocated a 16GB range > of physical addresses. There are up to four banks per node. The node > number is stuck into higher portions of the address, giving a gap between > nodes of 256GB. With a potential of 1024 nodes, you would have a very > large array. > > Additionally on our upcoming UV systems, there will potentially be a > hole between the bulk of memory and a small amount addressable at the > high end of the address range (slightly short of 16TB) with the typical > gap being on the order of 15TB.
Okay, that defeats the single-bitmap approach completely. Thanks for clarifying. Hannes --
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to
majordomo@vger.kernel.org
More majordomo info at
http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
http://www.tux.org/lkml/
Previous message: [
thread
] [
date
] [
author
]
Next message: [
thread
] [
date
] [
author
]
Messages in current thread:
[rfc][patch 0/3] bootmem2: a memory block-oriented boot ti ...
, Johannes Weiner
, (Mon May 5, 2:59 am)
Re: [rfc][patch 0/3] bootmem2: a memory block-oriented boo ...
, Johannes Weiner
, (Mon May 5, 4:23 am)
Re: [rfc][patch 0/3] bootmem2: a memory block-oriented boo ...
, Linus Torvalds
, (Mon May 5, 8:23 am)
Re: [rfc][patch 0/3] bootmem2: a memory block-oriented boo ...
, Robin Holt
, (Mon May 5, 9:04 am)
Re: [rfc][patch 0/3] bootmem2: a memory block-oriented boo ...
, Andi Kleen
, (Mon May 5, 11:58 am)
Re: [rfc][patch 0/3] bootmem2: a memory block-oriented boo ...
, Johannes Weiner
, (Tue May 6, 1:57 am)
Re: [rfc][patch 0/3] bootmem2: a memory block-oriented boo ...
, Johannes Weiner
, (Tue May 6, 2:00 am)
[RFC no patch yet] bootmem2: Another try
, Johannes Weiner
, (Wed May 7, 5:29 am)
Re: [RFC no patch yet] bootmem2: Another try
, Linus Torvalds
, (Wed May 7, 7:37 am)
Navigation
Create content
Mailing list archives
Recent posts
Popular discussions
linux-kernel
:
Greg KH
Re: [PATCH 1/1] staging: hv: Fix race condition on IC channel initialization (modi...
Brian Swetland
Re: Attempted summary of suspend-blockers LKML thread
Sam Ravnborg
[PATCH 05/11] x86: add X86_64 dependency to x86_64 specific symbols in Kconfig.x86...
Christoph Lameter
Re: [PATCH 02/40] mm: slab allocation fairness
Alexey Dobriyan
Re: [2.6.22.2 review 09/84] Fix rfkill IRQ flags.
git
:
Felipe Contreras
Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins
Paolo Ciarrocchi
Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins
Johannes Schindelin
Re: [PATCH] Fix install-doc-quick target
Peter Oberndorfer
Subject: [PATCH] fix stg edit command
Sverre Rabbelier
Re: [GSoC] What is status of Git's Google Summer of Code 2008 projects?
linux-netdev
:
Andi Kleen
Re: RFC: Nagle latency tuning
Badalian Vyacheslav
Re: tc filter flow hash question
Jarek Poplawski
Re: tc filter flow hash question
David Miller
Re: [RFC 0/5] generic rx recycling
Chuck Lever
Re: [RFC] ipv6: Change %pI6 format to output compacted addresses?
git-commits-head
:
Linux Kernel Mailing List
New device ID for sc92031 [1088:2031]
Linux Kernel Mailing List
e1000e: Expose MDI-X status via ethtool change
Linux Kernel Mailing List
NFS: Store pages from an NFS inode into a local cache
Linux Kernel Mailing List
powerpc/kexec: Add support for FSL-BookE
Linux Kernel Mailing List
arm/imx/gpio: GPIO_INT_{HIGH,LOW}_LEV are not necessarily constant
openbsd-misc
:
Theo de Raadt
Re: RES: OpenBSD on IBM System X3550 7879
Bret S. Lambert
Re: any web management gui for pf ?
Rob Shepherd
x86 hardware for router system
Leif Blixt
Re: Force passwordcheck in login.conf
Nick Holland
Re: Install OpenBSD from USB ?
Colocation donated by:
Syndicate