LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Dave Hansen <dave@linux.vnet.ibm.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Daniel Kiper <dkiper@net-space.pl>,
	ian.campbell@citrix.com, akpm@linux-foundation.org,
	andi.kleen@intel.com, haicheng.li@linux.intel.com,
	fengguang.wu@intel.com, jeremy@goop.org,
	dan.magenheimer@oracle.com, v.tolstov@selfip.ru, pasik@iki.fi,
	wdauchy@gmail.com, rientjes@google.com,
	xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org
Subject: Re: [PATCH R3 7/7] xen/balloon: Memory hotplug support for Xen balloon driver
Date: Thu, 10 Feb 2011 09:16:34 -0800	[thread overview]
Message-ID: <1297358194.6737.14488.camel@nimitz> (raw)
In-Reply-To: <20110210170152.GE12087@dumpdata.com>

On Thu, 2011-02-10 at 12:01 -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Feb 08, 2011 at 09:22:26AM -0800, Dave Hansen wrote:
> > On Mon, 2011-02-07 at 15:12 +0100, Daniel Kiper wrote:
> > > I agree. I discussed a bit about this problem with Jeremy, too. However,
> > > there are some problems to implement that solution now. First of all it is
> > > possible to online hotplugged memory using sysfs interface only in chunks
> > > called sections. It means that it is not possible online once again section
> > > which was onlined ealier partialy populated and now it contains new pages
> > > to online. In this situation sysfs interface emits Invalid argument error.
> > > In theory it should be possible to offline and then online whole section
> > > once again, however, if memory from this section was used is not possible
> > > to do that. It means that those properties does not allow hotplug memory
> > > in guest in finer granulity than section and sysfs interface is too inflexible
> > > to be used in that solution. That is why I decided to online hoplugged memory
> > > using API which does not have those limitations.
> > 
> > Sure, you have to _online_ the whole thing at once, but you don't have
> > to actually make the pages available.  You also don't need to hook in to
> > the memory resource code like you're doing.  It's sufficient to just try
> > and add the memory.  If you get -EEXIST, then you can't add it there, so
> > move up and try again.  
> > 
> > int xen_balloon_add_memory(u64 size)
> > {
> > 	unsigned long top_of_mem = max_pfn;
> > 	top_of_mem = section_align_up(top_of_mem);
> > 
> > 	while (1) {
> > 		int ret = add_memory(nid, top_of_mem, size);
> > 		if (ret == -EEXIST)
> > 			continue;
> > 		// error handling...
> > 		break;
> > 	}
> > 	return...;
> > }
> > 
> > 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 somehow have a vague recollection that the __weak was frowned upon? The issues
> were that when you compile a pv-ops kernel it can run as baremetal so the..

There are a bunch of alternatives to using 'weak'.  Any of those would
probably be fine as well.  Anything that allows us to check whether the
page should go back in to the allocator or the balloon.

> > void online_page(struct page *page)
> > {
> >         unsigned long pfn = page_to_pfn(page);
> > ...
> > -       __free_page(page);
> > +	arch_free_hotplug_page(page);
> > }
> > 
> > Then, have Xen override it:
> > 
> > void arch_free_hotplug_page(struct page *page)
> > {
> > 	if (xen_need_to_inflate_balloon())
> > 		put_page_in_balloon(page);	
> > 	else
> > 		__free_page(page);
> 
>  call above would get called even on baremetal (and would require the header
> file arch/x86/include/memory_hotplug.h to pull in header file from the balloon
> driver). If we are going to persue this it might be prudent to follow what we did for MSI:
> 
> 1525bf0d8f059a38c6e79353583854e1981b2e67
> 294ee6f89cfd629e276f632a6003a0fad7785dce
> b5401a96b59475c1c878439caecb8c521bdfd4ad

That looks a bit complicated for what I'm trying to do here, but
whatever works.  

-- Dave


  reply	other threads:[~2011-02-10 17:16 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-03 16:30 [PATCH R3 7/7] xen/balloon: Memory hotplug support for Xen balloon driver 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 [this message]
2011-02-11 23:13       ` Daniel Kiper
2011-02-11 23:22         ` Dave Hansen
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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=1297358194.6737.14488.camel@nimitz \
    --to=dave@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=andi.kleen@intel.com \
    --cc=dan.magenheimer@oracle.com \
    --cc=dkiper@net-space.pl \
    --cc=fengguang.wu@intel.com \
    --cc=haicheng.li@linux.intel.com \
    --cc=ian.campbell@citrix.com \
    --cc=jeremy@goop.org \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=pasik@iki.fi \
    --cc=rientjes@google.com \
    --cc=v.tolstov@selfip.ru \
    --cc=wdauchy@gmail.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).