Re: [PATCH 0/4] memblock related fixes for -tip

[Jeremy Fitzhardinge]

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