[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] libxl: Make 'xl vcpu-set' work properly on overcommited hosts.



On Wed, May 08, 2013 at 04:04:53PM +0100, Ian Campbell wrote:
> On Wed, 2013-05-08 at 15:29 +0100, Konrad Rzeszutek Wilk wrote:
> > On Wed, May 08, 2013 at 11:46:39AM +0100, Ian Campbell wrote:
> > > On Wed, 2013-05-08 at 11:32 +0100, George Dunlap wrote:
> > > > On Tue, May 7, 2013 at 9:40 PM, Konrad Rzeszutek Wilk
> > > > <konrad.wilk@xxxxxxxxxx> wrote:
> > > > > The libxl_cpu_bitmap_alloc(..) function, if provided with a zero
> > > > > value for max CPUs will call xc_get_max_cpus() which will retrieve
> > > > > the number of physical CPUs the host has. This is usually
> > > > > OK if the guest's maxvcpus <= host pcpus. But if the value
> > > > > is different, then the bitmap for VCPUs is limited by the
> > > > > number of CPUs the host has.
> > > > >
> > > > > This is incorrect as what we want is to hotplug in the guest
> > > > > the amount of CPUs that the user specified on the command line
> > > > > and not be limited by the amount of physical CPUs.
> > > > >
> > > > > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
> > > > 
> > > > Given the cost/benefits of this, I'm inclined to say this should wait
> > > > until the 4.4 window opens.  Having more guest vcpus than host pcpus
> > > > is not an urgent need, and there is a chance (however small) of this
> > > > exposing some other kind of bug.
> > > 
> > > Not disputing this.
> > > 
> > > I imagine the desire is to add vcpus to a guest after migrating to a
> > > larger host. If so then this should be in the commit log because you are
> > > right that as the commit message currently stands the immediate response
> > > is "why on earth..."
> > 
> > > 
> > > My only other concern would be that the existing code has a buffer
> > > overrun under these circumstances. I've not checked this either.
> > 
> > No over-runs, but this is a regression compared to Xend.
> 
> >From your updated description it seems like if you migrated to a larger
> host you could indeed plug more VCPUS, up to the limit on that host, is
> that right?
> 
> If that's the case then it sounds to me as if the xl behaviour is
> actually an improvement over xend's, except perhaps for some slightly
> niche test scenarios.

Well, overcommit comes in mind. Say you migrate to a 4PCPU box and you
have 12VCPUs, then you decide to go down to 4, then back to 16 before
migrating it to some other box. Can't do.

> 
> > Here is a bit of expanded git commit
> > 
> > 
> > From 42eef8cc5624bab907b6064fb183a5ae21b99df0 Mon Sep 17 00:00:00 2001
> > From: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
> > Date: Tue, 7 May 2013 16:32:20 -0400
> > Subject: [PATCH] libxl: Make 'xl vcpu-set' work properly on overcommited 
> > hosts.
> > 
> > The libxl_cpu_bitmap_alloc(..) function, if provided with a zero
> > value for max CPUs will call xc_get_max_cpus() which will retrieve
> > the number of physical CPUs the host has. This is usually
> > OK if the guest's maxvcpus <= host pcpus. But if the value
> > is different, then the bitmap for VCPUs is limited by the
> > number of CPUs the host has.
> > 
> > This is incorrect as what we want is to hotplug in the guest
> > the amount of CPUs that the user specified on the command line
> > and not be limited by the amount of physical CPUs.
> 
> IOW what I'm saying above is that this is statement is not axiomatically
> true, I think what is missing is the why anyone would want to do this.

See above.
> 
> > 
> > This means that a guest config like this:
> > 
> > vcpus=8
> > maxvcpus=32
> > 
> > and on a 4 PCPU machine doing
> > 
> > xl vcpu-set <guest name> 16
> > 
> > won't work. This is b/c the the size of the bitmap is one byte
> > so it can only hold up to 8 VCPUs. Hence anything above that
> > is going to be ignored.
> > 
> > Note that all of the libxl_cpu_bitmap_[test|set] silently ignore
> > any test or sets above its size:
> > 
> >      if (bit >= bitmap->size * 8)
> >          return 0;
> > 
> > so we were never notified off this bug.
> > 
> > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
> > ---
> >  tools/libxl/xl_cmdimpl.c |    2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> > 
> > diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> > index c1a969b..ef7f81b 100644
> > --- a/tools/libxl/xl_cmdimpl.c
> > +++ b/tools/libxl/xl_cmdimpl.c
> > @@ -4499,7 +4499,7 @@ static void vcpuset(uint32_t domid, const char* 
> > nr_vcpus)
> >          return;
> >      }
> >  
> > -    if (libxl_cpu_bitmap_alloc(ctx, &cpumap, 0)) {
> > +    if (libxl_cpu_bitmap_alloc(ctx, &cpumap, max_vcpus)) {
> >          fprintf(stderr, "libxl_cpu_bitmap_alloc failed\n");
> >          return;
> >      }
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.