On Thursday 31 January 2008 14:24:38 Ingo Molnar wrote:
>
> * Yinghai Lu <[EMAIL PROTECTED]> wrote:
>
> > ok, discard 3, and 4.
> >
> > how about 2 v2?
>
> i'm leaning towards v4, but the more fundamental breakage is in the
> early_node_mem() ad-hoc allocator that got butchered into this code
* Yinghai Lu <[EMAIL PROTECTED]> wrote:
> ok, discard 3, and 4.
>
> how about 2 v2?
i'm leaning towards v4, but the more fundamental breakage is in the
early_node_mem() ad-hoc allocator that got butchered into this code a
year ago:
commit a8062231d80239cf3405982858c02aea21a6066a
Author:
On Tuesday 29 January 2008 06:57:54 pm Andi Kleen wrote:
> On Tuesday 29 January 2008 20:16, Yinghai Lu wrote:
> > [PATCH 4/4] x86_64: increse MAX_EARLY_RES for NODE_DATA and bootmap
> >
> > otherise early_node_mem will use up these for 8 nodes system
>
> Yes t
On Tuesday 29 January 2008 20:16, Yinghai Lu wrote:
> [PATCH 4/4] x86_64: increse MAX_EARLY_RES for NODE_DATA and bootmap
>
> otherise early_node_mem will use up these for 8 nodes system
Yes this was the problem with my early_reserve node bootmem patch.
It adds a node limit.
But
[PATCH 4/4] x86_64: increse MAX_EARLY_RES for NODE_DATA and bootmap
otherise early_node_mem will use up these for 8 nodes system
Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
diff --git a/arch/x86/kernel/e820_64.c b/arch/x86/kernel/e820_64.c
index f8b7beb..e3d3815 100644
--- a/arch/x86/
5 matches
Mail list logo