Messages in this thread | | | Date | Wed, 13 Oct 2010 13:03:11 -0700 | From | Jeremy Fitzhardinge <> | Subject | Re: [PATCH 0/4] memblock related fixes for -tip |
| |
On 10/13/2010 11:20 AM, H. Peter Anvin wrote: > On 10/13/2010 09:31 AM, Jeremy Fitzhardinge wrote: >>> use ARCH_FIND_MEMBLOCK_AREA to select from them. >> Thanks, that fixes the problem. I would ideally like to make the the >> Xen code independent of the page allocation ordering, but it looks like >> it will be very tricky since we effectively make use of the pagetable as >> a way of storing one bit of information about each page before there's a >> struct page in place. >> >> So this patch looks good to me (but there's no need to make it a >> separate config option). >> > There isn't per se, but I have repeatedly expressed unhappiness about > x86 having a completely different allocation policy -- worse, bottom-up > is the absolutely worst possible allocation policy since low-address > memory is a precious resource for all kinds of odd requirements > (trampoline pages, ZONE_DMA, ZONE_DMA32 and so on.) > > Furthermore, I really, really disapprove of interfaces which carry > hidden semantics, such as allocation order.
Me too. I'd like to fix the Xen code to handle any pages.
> I have repeatedly asked that we do *not* do this on x86 if we're going > to go to a memblock-everywhere configuration. > > Now, if Xen needs it, there are few options that I can see in the short > term, neither of which makes me happy -- I would appreciate > > a) Add an explicit interface to allocate bottoms-up, and have Xen use it > because it needs it. This is appropriate if (and only if) the > allocations in Xen aren't underneath a bunch of extra layers.
The allocation is done in find_early_table_space() in x86/mm/init.c, so the allocation call itself can't be easily replaced, but I suppose some of the parameters could be global and tweaked by Xen code, but that's pretty ugly.
> c) Just accept it for now with the intent of getting rid of it as soon > as possible. I'd be fine pushing this for 2.6.37, but I'd like to get a > reasonably firm commitment try to come up with something better within > the next kernel cycle. > > Opinions?
I'm looking at ways of avoiding the dependency on bottom-up allocation at the moment. It looks like it's OK if I can assume that the pagetable is being allocated out of pages in the range e820_table_start-e820_table_end (though one hopes those will get renamed to something a bit more meaningful).
I should know how its going to turn out later today.
J
| |