Messages in this thread | | | From | Andi Kleen <> | Subject | Re: [PATCH 4/4] x86_64: increse MAX_EARLY_RES for NODE_DATA and bootmap | Date | Thu, 31 Jan 2008 14:34:30 +0100 |
| |
On Thursday 31 January 2008 14:24:38 Ingo Molnar wrote: > > * Yinghai Lu <Yinghai.Lu@Sun.COM> 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:
No it has nothing to do with early_node_mem which is just a thin wrapper around find_e820_area() anyways.
I think the problem is that the page alignment in bad_addr() and friends is not always correct. e.g. the early_reserve for the kernel in head64.c really need to round up to pages. I suspect (not 100% sure yet that is the core of the problem)
Note this was broken even before early reservation; the only difference was that it was all hard coded in bad_addr() then.
There were various hacks around this in the past, but none fixed the problem completely.
> commit a8062231d80239cf3405982858c02aea21a6066a > Author: Andi Kleen <ak@suse.de> > Date: Fri Apr 7 19:49:21 2006 +0200 > > [PATCH] x86_64: Handle empty PXMs that only contain hotplug memory > > ... > +static void * __init > +early_node_mem(int nodeid, unsigned long start, unsigned long end, > + unsigned long size) > > and we are now suffering the side-effects of that hack. > > what i suspect we need instead is a proper early-allocator that works in > the e820 space.
That is find_e820_area() or rather find_e820_area+early_reserve now.
I had this implemented as a shrink wrapped function earlier for lockdep too, but dropped the patch because there was a nasty ordering issue with the e820 command line parsing that i could not easily resolve.
-Andi
| |