LKML Archive on
help / color / mirror / Atom feed
From: Dave Hansen <>
To: Daniel Kiper <>
Subject: Re: [PATCH R3 7/7] xen/balloon: Memory hotplug support for Xen balloon driver
Date: Fri, 11 Feb 2011 15:22:18 -0800	[thread overview]
Message-ID: <1297466538.6737.18521.camel@nimitz> (raw)
In-Reply-To: <>

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

> > 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

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

  reply	other threads:[~2011-02-11 23:22 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-03 16:30 Daniel Kiper
2011-02-03 18:12 ` Dave Hansen
2011-02-07 14:12   ` Daniel Kiper
2011-02-08 17:22     ` Dave Hansen
2011-02-10 17:01       ` Konrad Rzeszutek Wilk
2011-02-10 17:16         ` Dave Hansen
2011-02-11 23:13       ` Daniel Kiper
2011-02-11 23:22         ` Dave Hansen [this message]
2011-02-10 16:53 ` Konrad Rzeszutek Wilk
2011-02-12  0:45   ` Daniel Kiper

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1297466538.6737.18521.camel@nimitz \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH R3 7/7] xen/balloon: Memory hotplug support for Xen balloon driver' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).