[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1154720180.7722.28.camel@keithlap>
Date: Fri, 04 Aug 2006 12:36:19 -0700
From: keith mannthey <kmannth@...ibm.com>
To: Mika Penttilä <mika.penttila@...umbus.fi>
Cc: lkml <linux-kernel@...r.kernel.org>, andrew <akpm@...l.org>,
discuss <discuss@...-64.org>, Andi Kleen <ak@...e.de>,
lhms-devel <lhms-devel@...ts.sourceforge.net>,
kame <kamezawa.hiroyu@...fujitsu.com>
Subject: Re: [Lhms-devel] [PATCH 4/10] hot-add-mem x86_64: Enable SPARSEMEM
in srat.c
On Fri, 2006-08-04 at 18:17 +0300, Mika Penttilä wrote:
> Keith Mannthey wrote:
> > From: Keith Mannthey <kmannth@...ibm.com>
> >
> > Enable x86_64 srat.c to share code between both reserve and sparsemem based add memory
> > paths. Both paths need the hot-add area node locality infomration (nodes_add). This
> > code refactors the code path to allow this.
> >
> > Signed-off-by: Keith Mannthey<kmannth@...ibm.com>
> >
> Ok nice, but.... hotadd_enough_memory() is broken, it does weird things
> with nd->start and nd->end which haven't been assigned even values yet.
> Also, mysterious business with find_e820_area and last_area_end...These
> areas are not in e820...
Thats for pointing out the breakage in hotadd_enough_memory. I think
the find_e820_area stuff is to make sure there box has the memory to
reserve the maps....but it doesn't look to do it right. I can take a
pass at a re-write for this function.
STAT hot-add memroy areas can be outside the e820. The e820 just
exposes the end of memory the is present in the box even though there
maybe add area on the other size of that.
For example my memory is layed out as follows.
SRAT: Node 0 PXM 0 0-80000000
SRAT: Node 0 PXM 0 0-470000000
SRAT: Node 0 PXM 0 0-1070000000
SRAT: hot plug zone found 470000000 - 1070000000
SRAT: Node 1 PXM 1 1070000000-1160000000
SRAT: Node 1 PXM 1 1070000000-3200000000
SRAT: hot plug zone found 1160000000 - 3200000000
The e820 ends at 1160000000 but there is still a possible add zone on
the other side of that.
The first hot plug zone is reserved by the e820 but no the 2nd.
> And why the reserve_bootmem_node()? Areas not RAM (per e820) are
> reserved anyways.
To make sure the areas are outside of the e820 are reserved.
Thanks,
Keith
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists