Re: [PATCH]: xl: fix broken cpupool-numa-split

[Juergen Gross <juergen.gross@ts.fujitsu.com>]

On 01/28/11 11:53, George Dunlap wrote:
> On Fri, Jan 28, 2011 at 6:26 AM, Juergen Gross
> <juergen.gross@ts.fujitsu.com>  wrote:
>> On 01/27/11 22:36, Andre Przywara wrote:
>>>
>>> Hi,
>>>
>>> the implementation of xl cpupool-numa-split is broken. It basically
>>> deals with only one poolid, but there are two to consider: the one from
>>> the original root CPUpool, the other from the newly created one.
>>
>> Uhh, silly copy and paste error! I think it happened when I introduced
>> libxl_cpupool_cpuadd_node()...
>> The correction is much easier. The root poolid is always 0. See attached
>> patch.
>
> Re patch itself: Acked-by: George Dunlap<george.dunlap@citrix.com>
>
> Re the cpupool interface:
>
> Hang on; if the root poolid is always 0, why does xc_cpupool_create()
> interpret a poolid of 0 as "XEN_SYSCTL_CPUPOOL_PAR_ANY"?  Doesn't that
> mean that if you're trying to create a new cpupool from cpus in the
> root pool, that you might get cpus from other pools?

No. It just creates a cpupool. As cpupool 0 is always created by the
hypervisor, it can't be created via libxc. So specifying 0 as poolid
selects the next free id.

The cpus are allocated later.

>
> If not, what's the point of the "CPUPOOL_PAR_ANY" parsing?

Perhaps you just don't care which poolid you get?


Juergen

-- 
Juergen Gross                 Principal Developer Operating Systems
TSP ES&S SWE OS6                       Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@ts.fujitsu.com
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html