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 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 <[EMAIL PROTECTED]> > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
