I disagree that it is redundant. There is actually a lot of power
there, and it was done for some very specific reasons. They're actually
especially important to your particular use, which I'll try to explain.
Say that you have a very fragmented lowmem-only machine and you want to
add a section of new mem_map[]. That's 512MB/PAGE_SIZE*sizeof(struct
page), which is between 4 and 8MB. So, you need 8MB of contiguous pages
for that mem_map[]. The way we designed it, you could always have that
extra section sitting there, unused. You have that overhead of 8MB
sitting there, but the benefit is that you can *ALWAYS* add memory.
I worry that the current patches as posted don't allow this kind of
behavior. If there was ever a need to preallocate the space, it would
need to do it inside the balloon driver itself and a way found to pass
that into the hotplug code.
It is especially important for Xen because all of the other
architectures, when getting a new section, magically have a large new
contiguous area out of which to get a new mem_map[] or other structures.
Xen doesn't actually have any contiguous memory at all since it will be
adding a page at a time. Could you add some new functionality to the
Xen driver and make sure to allocate the new section's mem_map[] inside
the section? That would get around the problem.
That might also be generalizable to anyone else that wants the "freshSure. The main problem is that 1-3 also ends up implicitly registering the new section with sysfs, so the bulk online interface becomes to usermode. If we make that optional (ie, a separate explicit call the memory-adder can choose to take) then everything is rosy.
meat" newly-hotplugged memory. Large page users might be other
consumers here.
OK, but the registering isn't a bad thing, either. You just don't want
all of the pages to be stuck back into the allocator. You want to suck
them into the balloon driver. Right?
Let's put a hook in online_page() to divert the new pages into your
driver instead of into the allocator. Problem solved, right?
We might do this with a free_hotplugged_page() function. It can, in the
initial introduction patch, just call free_page(). You can modify it
later to do your bidding.
This sounds like a tall order considering Xen's current tight coupling
between memory mapping and allocation, but I trust you and your
colleagues to get it done. :)