lkml.org 
[lkml]   [2010]   [Oct]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 0/4] memblock related fixes for -tip
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.

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.

b) Add it as a config option and make Xen select it (or depend on it).
Unfortunately this probably would mean using this option on any
paravirtualized kernel too, which would effectively mean Xen is
"infecting" the entire rest of the x86 architecture with a pessimal
allocation policy, which is extremely unfortunate.

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?

-hpa


\
 
 \ /
  Last update: 2010-10-13 20:23    [W:0.213 / U:0.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site