On Sat, 2011-02-12 at 00:13 +0100, Daniel Kiper wrote:
> On Tue, Feb 08, 2011 at 09:22:26AM -0800, Dave Hansen wrote:
> > You spoke about page alignment up there. Why is this section-aligned?
> > Should we make an "align to section" function in generic sparsemem code?
>
> It is done because all pages in relevant section starting from max_pfn
> to the end of that section do not have PG_reserved bit set. It was tested
> on Linux Kernel Ver. 2.6.32.x, however, I am going to do some tests on
> current Linus tree. Currently, I do not expect that "align to section"
> function is required by others.
It doesn't matter if it gets used by anybody else. It's a generic
function that fits in well with the other sparsemem code. It should go
there.
...
> > As for telling the hypervisor where you've mapped things, that should be
> > done in arch_add_memory().
> >
> > When it comes down to online_page(), you don't want your pages freed
> > back in to the buddy allocator, you want them put in to the balloon.
> > So, take the __free_page() in online_page(), and put a Xen hook in
> > there.
> >
> > +void __attribute__((weak)) arch_free_hotplug_page(struct page *page)
> > +{
> > + __free_page(page);
> > +}
>
> I think that this function should be registered dynamically at init
> stage by specific balloon driver (in this case Xen balloon driver).
That sounds fine to me. I guess we could use some of the subarch stuff
or the pv_ops structure to do it as well. This isn't exactly a hot
path, either, so I'm not worried about it being some kind of
conditional.
Really, anything that allows us to divert pages over to the Xen balloon
driver rather than the buddy allocator is probably just fine.
> > > Additionally, IIRC, add_memory() requires
> > > that underlying memory is available before its call.
> >
> > No, that's not correct. s390's memory isn't available until after it
> > calls vmem_add_mapping(). See arch/s390/mm/init.c
>
> I was right to some extent. First versions of memory hotplug code were
> written on the base of Linux Kernel Ver. 2.6.32.x. Tests done on that
> versions showed that add_memory() required that underlying memory should
> be available before its call. However, after short investigation it came
> out that there are some issues with some Xen calls. Those issues does
> not exists in current Linus tree.
Sounds good, I'm looking forward to your next patch.
-- Dave
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home