mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ian Campbell <ian.campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	<xen-devel@lists.xensource.com>, <alex@alex.org.uk>,
	<dcrisan@flexiant.com>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 1/2] xen/balloon: set a mapping for ballooned out pages
Date: Thu, 25 Jul 2013 04:31:07 +0100	[thread overview]
Message-ID: <1374723067.32286.34.camel@hastur.hellion.org.uk> (raw)
In-Reply-To: <20130724145838.GM2518@phenom.dumpdata.com>

On Wed, 2013-07-24 at 10:58 -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Jul 24, 2013 at 12:05:05PM +0100, Stefano Stabellini wrote:
> > On Tue, 23 Jul 2013, Konrad Rzeszutek Wilk wrote:
> > > On Tue, Jul 23, 2013 at 07:00:09PM +0100, Ian Campbell wrote:
> > > > On Tue, 2013-07-23 at 18:27 +0100, Stefano Stabellini wrote:
> > > > > +static int __cpuinit balloon_cpu_notify(struct notifier_block *self,
> > > > > +				    unsigned long action, void *hcpu)
> > > > > +{
> > > > > +	int cpu = (long)hcpu;
> > > > > +	switch (action) {
> > > > > +	case CPU_UP_PREPARE:
> > > > > +		if (per_cpu(balloon_scratch_page, cpu) != NULL)
> > > > > +			break;
> > > > 
> > > > Thinking about this a bit more -- do we know what happens to the per-cpu
> > > > area for a CPU which is unplugged and then reintroduced? Is it preserved
> > > > or is it reset?
> > > > 
> > > > If it is reset then this gets more complicated :-( We might be able to
> > > > use the core mm page reference count, so that when the last reference is
> > > > removed the page is automatically reclaimed. We can obviously take a
> > > > reference whenever we add a mapping of the trade page, but I'm not sure
> > > > we are always on the path which removes such mappings... Even then you
> > > > could waste pages for some potentially large amount of time each time
> > > > you replug a VCPU.
> > > > 
> > > > Urg, I really hope the per-cpu area is preserved!
> > > 
> > > It is. During bootup time you see this:
> > > 
> > > [    0.000000] smpboot: Allowing 128 CPUs, 96 hotplug CPU
> > > [    0.000000] setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:128 nr_node_ids:1
> > > 
> > > which means that all of the per_CPU are shrunk down to 128 (from 
> > > CONFIG_NR_CPUS=512 was built with) and stays for the lifetime of the kernel.
> > > 
> > > You might have to clear it when the vCPU comes back up though - otherwise you
> > > will have garbage.
> > 
> > I don't see anything in the hotplug code that would modify the value of
> > the per_cpu area of offline cpus.
> 
> You might have never onlined the CPUs and the kernel is built with DEBUG options
> which poison the page.
> 
> Anyhow, doing a memset seems like a prudent thing to do? Perhaps when
> built with CONFG_DEBUG_XENFS you add poison values to it?

The point is that the patches need for the per-cpu areas to *not* be
reinitialised over a vcpu unplug+plug, otherwise we will leak the
original page when we allocate the new one on plug.

We can't just free the page on vcpu unplug because it might still be in
use.

Ian.


  reply	other threads:[~2013-07-25  3:31 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <alpine.DEB.2.02.1307231820570.4893@kaball.uk.xensource.com>
2013-07-23 17:27 ` Stefano Stabellini
2013-07-23 18:00   ` Ian Campbell
2013-07-23 19:05     ` Konrad Rzeszutek Wilk
2013-07-24 11:05       ` Stefano Stabellini
2013-07-24 14:58         ` Konrad Rzeszutek Wilk
2013-07-25  3:31           ` Ian Campbell [this message]
2013-07-29 14:10             ` Konrad Rzeszutek Wilk
2013-08-04 14:30               ` Stefano Stabellini
2013-07-24 17:37   ` [Xen-devel] " David Vrabel
2013-07-23 17:27 ` [PATCH v3 2/2] xen/m2p: use GNTTABOP_unmap_and_replace to reinstate the original mapping Stefano Stabellini

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=1374723067.32286.34.camel@hastur.hellion.org.uk \
    --to=ian.campbell@citrix.com \
    --cc=alex@alex.org.uk \
    --cc=dcrisan@flexiant.com \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stefano.stabellini@eu.citrix.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

Powered by JetHome