Re: [Xen-devel] [PATCH v3 ]libxl: allow to set more than 31 vcpus

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2012-06-01 at 10:32 +0100, Dario Faggioli wrote:
> On Fri, 2012-06-01 at 09:58 +0100, Ian Campbell wrote: 
> > > > And, in future, there are some cases may not need to allocate max size 
> > > > cpumap too
> > > > So it's better to extend the current interface.
> > > > 
> > > Well, maybe... Who knows what future reserves ?!? :-D
> > > 
> > > Anyway, although I see your point, I really really dislike the new
> > > parameter in libxl_cpumap_alloc(),
> > 
> > What about it do you dislike? The special meaning of 0 or its existence
> > at all?
> > 
> It's pretty much all about its existence, given the fact it is _always_
> 0 apart from one single case, where it could well be zero as well. :-)

Except as discussed below it can't be zero..

> It's just I find it uncomfortable to have it, but of course I could live
> with it if it buys something. It's the latter I'm not sure I see...
> 
> > > but of course it is not something up
> > > to me to decide, neither it is something I'd loose some sleep for. :-P
> > 
> > You could give vcpus > pcpus (dumb, but e.g. for debugging) and in that
> > case the existing libxl_cpumap_alloc behaviour (which sizes based on the
> > # of phys cpus) is incorrect. 
> >
> Mmm... Maybe this is still related to the fact that on all the test
> boxes I've used, libxl_get_max_cpus() returns something higher than the
> actual physical CPU count of those boxes themselves, but I just created
> an 18 VCPUs VM on my 16 PCPUs test machine... I take the above like you
> can't, can you?

I think libxl_get_max_cpus and/or libxl_cpumap_alloc involved some
amount of rounding up, if you tried to create a 33 vcpu guest on that
machine (or a machine with <= 32 cpus) it may not work...

> Maybe it is that *_max_cpus() logic that needs some attention? :-O

max_cpus returns the max number of physical cpus, and I think it does so
correctly (perhaps with some slop at the top end). In some cases we want
to talk about virtual cpus and this change lets us size cpumap's of
virtual cpus more appropriately (be that larger or smaller than the
number of physical cpus).


> 
> > I suggested that rather than having
> > libxl_cpumap_alloc_size() we just combine this with the existing fn with
> > a new parameter.
> > 
> Yeah, I checked that in the archives, and that's not the issue for me.
> If the we decide we want the thing, I'm fine with both the 'add new' and
> 'modify the existing' approaches. 
> 
> Thanks and Regards,
> Dario
> |



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