login
Login
/
Register
Search
Search this site:
Forums
News
Blogs
Features
Site
Home
»
Mailing list archives
»
linux-kernel
»
2010
»
October
»
27
Re: early_node_mem()'s memory allocation policy
view
thread
Previous message: [
thread
] [
date
] [
author
]
Next message: [
thread
] [
date
] [
author
]
[view in full thread]
From: Konrad Rzeszutek Wilk
Subject:
Re: early_node_mem()'s memory allocation policy
Date: Wednesday, October 27, 2010 - 7:28 am
On Tue, Oct 26, 2010 at 10:49:33PM -0700, Yinghai Lu wrote:
quoted text
> On 10/26/2010 03:18 PM, Jeremy Fitzhardinge wrote: > > We're seeing problems under Xen where large portions of the memory > > could be reserved (because they're not yet physically present, even > > though the appear in E820), and the 'start' and 'end' early_node_mem() > > is choosing is entirely within that reserved range. > > > > Also, the code seems dubious because it adjusts start and end without > > regarding how much space it is trying to allocate: > > > > /* extend the search scope */ > > end = max_pfn_mapped << PAGE_SHIFT; > > if (end > (MAX_DMA32_PFN<<PAGE_SHIFT)) > > start = MAX_DMA32_PFN<<PAGE_SHIFT; > > else > > start = MAX_DMA_PFN<<PAGE_SHIFT; > > > > what if max_pfn_mapped is only a few pages larger than MAX_DMA32_PFN, > > and that is smaller than the size it is trying to allocate? > > > > I tried just removing the start and end adjustments in early_node_mem() > > and the kernel booted fine under Xen, but it seemed to allocate at a > > very low address. Should the for_each_active_range_index_in_nid() loop > > in find_memory_core_early() be iterating from high to low addresses? If > > the allocation could be relied on to be top-down, then you wouldn't need > > to adjust start at all, and it would return the highest available memory > > in a natural way. > > please check
It definitly gets us across that hump. Thanks.
quoted text
> > [PATCH] x86, memblock: Fix early_node_mem with big reserved region. > > Jeremy said Xen could reserve huge mem but still show as ram in e820. > > early_node_mem could not find range because of start/end adjusting. > > Let's use memblock_find_in_range instead ***_node. So get real top down in fallback path. > > Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
quoted text
> > diff --git a/arch/x86/mm/numa_64.c b/arch/x86/mm/numa_64.c > index 60f4985..7ffc9b7 100644 > --- a/arch/x86/mm/numa_64.c > +++ b/arch/x86/mm/numa_64.c > @@ -178,11 +178,8 @@ static void * __init early_node_mem(int nodeid, unsigned long start, > > /* extend the search scope */ > end = max_pfn_mapped << PAGE_SHIFT; > - if (end > (MAX_DMA32_PFN<<PAGE_SHIFT)) > - start = MAX_DMA32_PFN<<PAGE_SHIFT; > - else > - start = MAX_DMA_PFN<<PAGE_SHIFT; > - mem = memblock_x86_find_in_range_node(nodeid, start, end, size, align); > + start = MAX_DMA_PFN << PAGE_SHIFT; > + mem = memblock_find_in_range(start, end, size, align); > if (mem != MEMBLOCK_ERROR) > return __va(mem); >
--
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:
early_node_mem()'s memory allocation policy
, Jeremy Fitzhardinge
, (Tue Oct 26, 3:18 pm)
Re: early_node_mem()'s memory allocation policy
, Yinghai Lu
, (Tue Oct 26, 10:49 pm)
Re: early_node_mem()'s memory allocation policy
, Konrad Rzeszutek Wilk
, (Wed Oct 27, 7:28 am)
Re: early_node_mem()'s memory allocation policy
, Jeremy Fitzhardinge
, (Wed Oct 27, 1:21 pm)
[PATCH] x86, memblock: Fix early_node_mem with big reserve ...
, Yinghai Lu
, (Thu Oct 28, 9:50 am)
[tip:x86/urgent] x86, memblock: Fix early_node_mem with bi ...
, tip-bot for Yinghai Lu
, (Thu Oct 28, 4:40 pm)
Navigation
Mailing list archives
Recent posts
Popular discussions
linux-kernel
:
Alexey Dobriyan
Re: [2.6.22.2 review 09/84] Fix rfkill IRQ flags.
Michael Moore
Re: underage models, pre teen models, lolita porn, young preteens, little lolitas
Alex Riesen
Re: [PATCH 4/7] lib: Introduce strnstr()
Thomas Gleixner
[ANNOUNCE] 2.6.31-rc6-rt2
Mathieu Desnoyers
Re: Linux 2.6.25-rc2
git
:
Blaisorblade
git-unpack-objects < pack file in repository doesn't work!
Matthieu Moy
Re: Cloning empty repositories, was Re: What is the idea for bare repositories?
Linus Torvalds
Re: Untracked working tree files
Peter Karlsson
Re: CRLF problems with Git on Win32
Johannes Schindelin
Re: [PATCH 4/4] git-rebase -i: New option to support rebase with merges
linux-netdev
:
Alan Menegotto
Re: Linux networking implementation and packet capture
Andrew Morton
Re: [PATCH] PHYLIB: IRQ event workqueue handling fixes
Timo Teräs
ip xfrm policy semantics
Jarek Poplawski
Re: [PATCH]: Fix queueing return values...
David Miller
Re: [PATCH 1/2] netdev: bfin_mac: enable bfin_mac net dev driver for BF51x
git-commits-head
:
Linux Kernel Mailing List
Blackfin: don't give CPU its own line in traps output
Linux Kernel Mailing List
No need to do lock_super() for exclusion in generic_shutdown_super()
Linux Kernel Mailing List
x86, msr: Export the register-setting MSR functions via /dev/*/msr
Linux Kernel Mailing List
MIPS: SMTC: Fix lockup in smtc_distribute_timer
Linux Kernel Mailing List
powerpc: gamecube/wii: usbgecko bootwrapper console support
openbsd-misc
:
Aaron Mason
Re: Defending OpenBSD Performance
Henning Brauer
Re: Defending OpenBSD Performance
Henning Brauer
Re: Defending OpenBSD Performance
Christiano Farina Haesbaert
Re: Defending OpenBSD Performance
Nick Holland
Re: 1 out of 3 hunks failed--saving rejects to kerberosV/src/lib/krb5/crypto.c.rej
Colocation donated by:
Syndicate