Re: [Xen-devel] [PATCH 4 of 4] Support new xl command cpupool-numa-split

[Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>]

On Wed, 2010-12-08 at 12:20 +0000, Juergen Gross wrote:
> On 12/08/10 12:16, Ian Campbell wrote:
> >
> > There seems to be no way to find out the number of pools without also
> > getting all the info about them, which is a shame.
> 
> Taking a quick look I couldn't spot any way how to find out the number
> of domains without also getting all the info about them, too...

Yeah. It's not important, just an observation.
> 
> >
> >> +    /* Reset Pool-0 to 1st node */
> >> +    node = topology->nodemap.array[0];
> >> +    libxl_for_each_cpu(c, cpumap) {
> >> +        if (!libxl_cpumap_test(&cpumap, c)&&  (c<  
> >> topology->nodemap.entries)&&
> >> +            (topology->nodemap.array[c] == node)) {
> >> +            ret = -libxl_cpupool_cpuadd(&ctx, poolid, c);
> >> +            if (ret) {
> >> +                fprintf(stderr, "error on adding cpu to Pool-0\n");
> >> +                goto out;
> >> +            }
> >> +            libxl_cpumap_reset(&freemap, c);
> >
> > (nt really related to this series but I wish this was called
> > libxl_cpumap_clear, I had to go check it wasn't resetting the whole map
> > or something...)
> 
> Hmm, do you really think so?
> It would make me to check whether it is clearing the whole map :-)

;-) I think I'm just used to the Linux clear_bit type naming scheme.

> I think the second parameter is a strong hint :-)

True.


> > Can this loop be merged with the preceding loop, with the body being the
> > else case of the if?
> 
> No. I have to add new cpus first to avoid a cpupool without cpus in between.

ok.

I was thinking that because this function only gets here if there is a
single pool that all CPUs must be in that pool -- but that's not
actually true is it? Even if that were the common case there's nothing
to enforce that.

> > Do we want to rename Pool-0 at some point too or do we rely on that name
> > elsewhere?
> 
> Good question. There is a hard coded "Pool-0" reference in libxl, but this
> could easily be changed.
> I'm not sure about implications in xm/xend. I'll check this.

I don't think there is a particularly strong requirement to allow xend
and xl to coexist. I'd recommend just leaving xend doing what it does
today and fix xl/libxl only.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel