8 a.m.
There are a few things I gathered on this issue. This affects
NUMA setups, where basically if a domain must be placed on a given cell
it is not good to let the hypervisor place it first with its own heuristics
and then later migrate it to a different set of CPU, but better to
instruct the hypervisor to start said domain on the given set.
- For Xen it is possible to instruct the hypervisor by passing
(cpus '2,3') in the SExpr where the argument is a list of
the physical processors allowed
- For KVM I think the standard way would be to select the
cpuset using sched_setaffinity() between the fork of the
current process and the exec of the qemu process
- there is no need (from a NUMA perspective) to do fine grained
allocation at that point, as long as the domain can be restricted
to a given cell at startup, then if needed virDomainPinVcpu() can be
used later to do more precise pinning in order to try to optimize
placement
- to be able to instruct the hypervisor at creation time adding the
information in the domain XML description looks the more natural way
(another option would be to force to use virDomainDefineXML, add a
call using the resulting virDomainPtr to define the set, and
then virDomainCreate would be used to do the actual start)
+ the good point of having this embedded in the XML is that
we still have all informations about the domain settings in
the XML, if we want to restart it later
+ the bad point is that we need to fetch and carry this extra
information when doing XML dumps to not loose it for example
when manipulating the domain to add or remove devices
- extracting a cpuset can still be an heavy operation, for example
if using xend on need one RPC per vcpu in the domain, the cpuset
being constructed by OR'ing logically all cpumaps used by the
vcpus of the domain (though in most case this will be the full
map after the first CPU and can be stopped immediately)
- for the mapping at the XML level I suggest to use a simple extension
to the <vcpu>n</vcpu> and extend it to
<vcpu cpuset='2,3'>n</vcpu>
with a limited syntax which is just the comma separated list of
allowed CPU numbers (if the code actually detects such a cpuset is
in effect i.e. in general this won't be added).
Internally implementing this should not be too hard, I would probably refactor
some of the existing parsing code, provide functions to get the cpuset and
the number of physical processors.
Does this sounds okay ?
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
10:03 a.m.
On Thu, Oct 11, 2007 at 09:00:14AM -0400, Daniel Veillard wrote:
There are a few things I gathered on this issue. This affects
NUMA setups, where basically if a domain must be placed on a given cell
it is not good to let the hypervisor place it first with its own heuristics
and then later migrate it to a different set of CPU, but better to
instruct the hypervisor to start said domain on the given set.
- For Xen it is possible to instruct the hypervisor by passing
(cpus '2,3') in the SExpr where the argument is a list of
the physical processors allowed
- For KVM I think the standard way would be to select the
cpuset using sched_setaffinity() between the fork of the
current process and the exec of the qemu process
Yep, as with Xen, this will only let you specify coarse mapping at time
of creating the VM. ie you can say 'this VM is allow to run on pCPUs 1 & 3',
but you can't say 'this VM's vCPU 1 is allow on pCPU 1 and vCPU 2 is allowed
on pCPU 3'. This is because KVM has one thread per vCPU, and at the time
of creating the VM the, vCPU threads don't yet exist & so there's nothing
to pin. Not a huge problem really, just something we should document.
Basically we are setting VM affinity at time of creationg. VCPU affinity
can be set once a VM is running to fine-tune.
- there is no need (from a NUMA perspective) to do fine grained
allocation at that point, as long as the domain can be restricted
to a given cell at startup, then if needed virDomainPinVcpu() can be
used later to do more precise pinning in order to try to optimize
placement
Yep, from a NUMA pov we're only concerned with the VM memory allocation,
so it is sufficient to consider VM affinity and not vCPU affinity.
- to be able to instruct the hypervisor at creation time adding
the
information in the domain XML description looks the more natural way
(another option would be to force to use virDomainDefineXML, add a
call using the resulting virDomainPtr to define the set, and
then virDomainCreate would be used to do the actual start)
+ the good point of having this embedded in the XML is that
we still have all informations about the domain settings in
the XML, if we want to restart it later
+ the bad point is that we need to fetch and carry this extra
information when doing XML dumps to not loose it for example
when manipulating the domain to add or remove devices
- extracting a cpuset can still be an heavy operation, for example
if using xend on need one RPC per vcpu in the domain, the cpuset
being constructed by OR'ing logically all cpumaps used by the
vcpus of the domain (though in most case this will be the full
map after the first CPU and can be stopped immediately)
Fetching /xend/domain/%s?op=vcpuinfo lets us get info for all vCPUs
in a domain in a single RPC doesn't it ? In any case we should first
just try the hypercall - in all normal scenarios that'll work fine.
- for the mapping at the XML level I suggest to use a simple
extension
to the <vcpu>n</vcpu> and extend it to
<vcpu cpuset='2,3'>n</vcpu>
with a limited syntax which is just the comma separated list of
allowed CPU numbers (if the code actually detects such a cpuset is
in effect i.e. in general this won't be added).
It doesn't make sense to me to include the info at a vCPU level in the
XML, since our granularity at time of creation is only at a VM level.
When dumping XML, the VM's affinity is basically the union of the affinity
of all of its pCPUs.
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
10:45 a.m.
* Daniel Veillard <veillard(a)redhat.com> [2007-10-11 08:01]:
There are a few things I gathered on this issue. This affects
NUMA setups, where basically if a domain must be placed on a given cell
it is not good to let the hypervisor place it first with its own heuristics
and then later migrate it to a different set of CPU, but better to
instruct the hypervisor to start said domain on the given set.
- For Xen it is possible to instruct the hypervisor by passing
(cpus '2,3') in the SExpr where the argument is a list of
the physical processors allowed
A bit more detail here just FYI:
Xen takes the cpu list and converts that into an affinity bitmap that is
then applied to each vcpu allocated to the guest.
- For KVM I think the standard way would be to select the
cpuset using sched_setaffinity() between the fork of the
current process and the exec of the qemu process
Yep.
- there is no need (from a NUMA perspective) to do fine grained
allocation at that point, as long as the domain can be restricted
to a given cell at startup, then if needed virDomainPinVcpu() can be
used later to do more precise pinning in order to try to optimize
placement
kvm-46 added user-space allocated memory which means that we can use
libnuma/numactl to set the approriate node.
- to be able to instruct the hypervisor at creation time adding
the
information in the domain XML description looks the more natural way
(another option would be to force to use virDomainDefineXML, add a
call using the resulting virDomainPtr to define the set, and
then virDomainCreate would be used to do the actual start)
+ the good point of having this embedded in the XML is that
we still have all informations about the domain settings in
the XML, if we want to restart it later
+ the bad point is that we need to fetch and carry this extra
information when doing XML dumps to not loose it for example
when manipulating the domain to add or remove devices
- extracting a cpuset can still be an heavy operation, for example
if using xend on need one RPC per vcpu in the domain, the cpuset
being constructed by OR'ing logically all cpumaps used by the
vcpus of the domain (though in most case this will be the full
map after the first CPU and can be stopped immediately)
Yeah, that might be a decent patch to xend - build up an array of
affinity masks for each vcpu.
- for the mapping at the XML level I suggest to use a simple
extension
to the <vcpu>n</vcpu> and extend it to
<vcpu cpuset='2,3'>n</vcpu>
with a limited syntax which is just the comma separated list of
allowed CPU numbers (if the code actually detects such a cpuset is
in effect i.e. in general this won't be added).
I think we should support the same cpuset notation that Xen supports,
which means including ranges (1-4) and negation (^1). These two
features make describing large ranges much more compact.
Internally implementing this should not be too hard, I would probably refactor
some of the existing parsing code, provide functions to get the cpuset and
the number of physical processors.
Does this sounds okay ?
Yeah, I think this covers everything we'd need.
--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253 T/L: 678-9253
ryanh(a)us.ibm.com
4:09 a.m.
On Thu, Oct 11, 2007 at 10:45:44AM -0500, Ryan Harper wrote:
* Daniel Veillard <veillard(a)redhat.com> [2007-10-11 08:01]:
> - for the mapping at the XML level I suggest to use a simple extension
> to the <vcpu>n</vcpu> and extend it to
> <vcpu cpuset='2,3'>n</vcpu>
> with a limited syntax which is just the comma separated list of
> allowed CPU numbers (if the code actually detects such a cpuset is
> in effect i.e. in general this won't be added).
I think we should support the same cpuset notation that Xen supports,
which means including ranges (1-4) and negation (^1). These two
features make describing large ranges much more compact.
on input I guess it makes sense. But we can't garantee to have such
a compact representation on output.
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
9:53 a.m.
On Thu, Oct 11, 2007 at 10:45:44AM -0500, Ryan Harper wrote:
* Daniel Veillard <veillard(a)redhat.com> [2007-10-11 08:01]:
> - for the mapping at the XML level I suggest to use a simple extension
> to the <vcpu>n</vcpu> and extend it to
> <vcpu cpuset='2,3'>n</vcpu>
> with a limited syntax which is just the comma separated list of
> allowed CPU numbers (if the code actually detects such a cpuset is
> in effect i.e. in general this won't be added).
I think we should support the same cpuset notation that Xen supports,
which means including ranges (1-4) and negation (^1). These two
features make describing large ranges much more compact.
Enclosed is a rewrite of the cpuset notations, which can plug as
a replacement for the current code in xend_internals, it should support
the existing syntax currently used to parse xend topology strings,
and also alllow ranges and negation. It's not as a patch but as a
standlone replacement program which can be used to test (in spirit
of the old topology.c one from Beth).
I guess that's okay, check the test output (and possibly extend the
test cases in tests array), It tried to think of everything including
the weird \\n python xend bug and the 'no cpus' in cell cases.
Just dump tst.c in libvirt/src, add $(INCLUDES) to the
$(CC) $(CFLAGS) -I../include -o tst tst.c .... line and run
make tst
./tst
and check the output (also enclosed),
The parsing is done in a slightly different way, but that should
not change the output,
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
8:10 p.m.
On Wed, 17 Oct 2007 10:53:17 -0400 Daniel Veillard wrote:
On Thu, Oct 11, 2007 at 10:45:44AM -0500, Ryan Harper wrote:
> I think we should support the same cpuset notation that Xen supports,
> which means including ranges (1-4) and negation (^1). These two
> features make describing large ranges much more compact.
Enclosed is a rewrite of the cpuset notations, which can plug as
a replacement for the current code in xend_internals, it should support
the existing syntax currently used to parse xend topology strings,
and also alllow ranges and negation. It's not as a patch but as a
standlone replacement program which can be used to test (in spirit
of the old topology.c one from Beth).
I guess that's okay, check the test output (and possibly extend the
test cases in tests array), It tried to think of everything including
the weird \\n python xend bug and the 'no cpus' in cell cases.
Just dump tst.c in libvirt/src, add $(INCLUDES) to the
$(CC) $(CFLAGS) -I../include -o tst tst.c .... line and run
make tst
./tst
and check the output (also enclosed),
The parsing is done in a slightly different way, but that should
not change the output,
I checked the test output. It seems work fine to me !
And also, how about this one for specifying "all" as an input ?
--- tst.c_org 2007-10-17 20:52:10.000000000 -0400
+++ tst.c 2007-10-17 20:52:57.000000000 -0400
@@ -25,6 +25,7 @@ virXendError(void *conn, virErrorNumber
#ifdef STANDALONE
const char *tests[] = {
+ "node0:all",
"node0:0-3,7,9-10\n node1:11-14\n",
"node0:4,7\n",
"node0:8-9,11\n",
@@ -166,11 +167,19 @@ parseCpuSet(virConnectPtr conn, const ch
while ((*cur != 0) && (*cur != sep)) {
/*
- * 3 constructs are allowed:
+ * 4 constructs are allowed:
* - N : a single CPU number
* - N-M : a range of CPU numbers with N < M
* - ^N : remove a single CPU number from the set
+ * - all : apply the cpumap to all vcpus
*/
+ if ( !strcmp(cur, "all") ) {
+ char buf[256];
+ memset(&buf, 0, sizeof(buf));
+ sprintf(buf, "0-%d", maxcpu);
+ cur = buf;
+ }
+
if (*cur == '^') {
cur++;
neg = 1;
Thanks,
Saori Fukuta
3:50 a.m.
On Thu, Oct 18, 2007 at 10:10:59AM +0900, Saori Fukuta wrote:
On Wed, 17 Oct 2007 10:53:17 -0400 Daniel Veillard wrote:
> On Thu, Oct 11, 2007 at 10:45:44AM -0500, Ryan Harper wrote:
> > I think we should support the same cpuset notation that Xen supports,
> > which means including ranges (1-4) and negation (^1). These two
> > features make describing large ranges much more compact.
>
> Enclosed is a rewrite of the cpuset notations, which can plug as
> a replacement for the current code in xend_internals, it should support
> the existing syntax currently used to parse xend topology strings,
> and also alllow ranges and negation. It's not as a patch but as a
> standlone replacement program which can be used to test (in spirit
> of the old topology.c one from Beth).
> I guess that's okay, check the test output (and possibly extend the
> test cases in tests array), It tried to think of everything including
> the weird \\n python xend bug and the 'no cpus' in cell cases.
> Just dump tst.c in libvirt/src, add $(INCLUDES) to the
> $(CC) $(CFLAGS) -I../include -o tst tst.c .... line and run
> make tst
> ./tst
> and check the output (also enclosed),
> The parsing is done in a slightly different way, but that should
> not change the output,
I checked the test output. It seems work fine to me !
And also, how about this one for specifying "all" as an input ?
All is the default, i.e. you don't specify a cpumap in the
XML format.
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
9:14 p.m.
Daniel Veillard wrote:
On Thu, Oct 11, 2007 at 10:45:44AM -0500, Ryan Harper wrote:
>* Daniel Veillard <veillard(a)redhat.com> [2007-10-11 08:01]:
>
>
>> - for the mapping at the XML level I suggest to use a simple extension
>> to the <vcpu>n</vcpu> and extend it to
>> <vcpu cpuset='2,3'>n</vcpu>
>> with a limited syntax which is just the comma separated list of
>> allowed CPU numbers (if the code actually detects such a cpuset is
>> in effect i.e. in general this won't be added).
>>
>>
>I think we should support the same cpuset notation that Xen supports,
>which means including ranges (1-4) and negation (^1). These two
>features make describing large ranges much more compact.
>
>
Enclosed is a rewrite of the cpuset notations, which can plug as
a replacement for the current code in xend_internals, it should support
the existing syntax currently used to parse xend topology strings,
and also alllow ranges and negation. It's not as a patch but as a
standlone replacement program which can be used to test (in spirit
of the old topology.c one from Beth).
I guess that's okay, check the test output (and possibly extend the
test cases in tests array), It tried to think of everything including
the weird \\n python xend bug and the 'no cpus' in cell cases.
Just dump tst.c in libvirt/src, add $(INCLUDES) to the
$(CC) $(CFLAGS) -I../include -o tst tst.c .... line and run
make tst
./tst
and check the output (also enclosed),
The parsing is done in a slightly different way, but that should
not change the output,
Daniel
...
------------------------------------------------------------------------
cur = str;
while (*cur != 0) {
/*
* Find the next NUMA cell described in the xend output
*/
cur = strstr(cur, "node");
if (cur == NULL)
break;
cur += 4;
cell = parseCpuNumber(&cur, maxcpu);
This is certainly a nit, but I might change parseCpuNumber to
parseNumber, since it looks a little odd that you are getting the cell
id from the cpu number. A nit to be sure!
if (cell < 0)
goto parse_error;
skipSpaces(&cur);
if (*cur != ':')
goto parse_error;
cur++;
skipSpaces(&cur);
if (!strncmp (cur, "no cpus", 7)) {
nb_cpus = 0;
for (cpu = 0;cpu < maxcpu;cpu++)
cpuset[cpu] = 0;
} else {
nb_cpus = parseCpuSet(conn, &cur, 'n', cpuset, maxcpu);
Other than our discussion on #virt about handling of ^N specifications
in parseCpuSet, looks good!
------------------------------------------------------------------------
--
Elizabeth Kon (Beth)
IBM Linux Technology Center
Open Hypervisor Team
email: eak(a)us.ibm.com
3:53 a.m.
On Wed, Oct 17, 2007 at 10:14:56PM -0400, beth kon wrote:
Daniel Veillard wrote:
>On Thu, Oct 11, 2007 at 10:45:44AM -0500, Ryan Harper wrote:
>
>
>>* Daniel Veillard <veillard(a)redhat.com> [2007-10-11 08:01]:
>>
>>
>>> - for the mapping at the XML level I suggest to use a simple extension
>>> to the <vcpu>n</vcpu> and extend it to
>>> <vcpu cpuset='2,3'>n</vcpu>
>>> with a limited syntax which is just the comma separated list of
>>> allowed CPU numbers (if the code actually detects such a cpuset is
>>> in effect i.e. in general this won't be added).
>>>
>>>
>>I think we should support the same cpuset notation that Xen supports,
>>which means including ranges (1-4) and negation (^1). These two
>>features make describing large ranges much more compact.
>>
>>
>
> Enclosed is a rewrite of the cpuset notations, which can plug as
>a replacement for the current code in xend_internals, it should support
>the existing syntax currently used to parse xend topology strings,
>and also alllow ranges and negation. It's not as a patch but as a
>standlone replacement program which can be used to test (in spirit
>of the old topology.c one from Beth).
> I guess that's okay, check the test output (and possibly extend the
>test cases in tests array), It tried to think of everything including
>the weird \\n python xend bug and the 'no cpus' in cell cases.
>Just dump tst.c in libvirt/src, add $(INCLUDES) to the
>$(CC) $(CFLAGS) -I../include -o tst tst.c .... line and run
>make tst
>./tst
>and check the output (also enclosed),
> The parsing is done in a slightly different way, but that should
>not change the output,
>
>Daniel
>
>
>
>
>
...
>------------------------------------------------------------------------
> cur = str;
> while (*cur != 0) {
> /*
> * Find the next NUMA cell described in the xend output
> */
> cur = strstr(cur, "node");
> if (cur == NULL)
> break;
> cur += 4;
> cell = parseCpuNumber(&cur, maxcpu);
>
>
This is certainly a nit, but I might change parseCpuNumber to
parseNumber, since it looks a little odd that you are getting the cell
id from the cpu number. A nit to be sure!
well, the only problem is if you have more cells than maxcpu,
which doesn't make that much sense. Since we are testing against
maxcpu I really think we should keep the function name, I can
duplicate code and make a simpler function just for parsing the
cell no.
> if (cell < 0)
> goto parse_error;
> skipSpaces(&cur);
> if (*cur != ':')
> goto parse_error;
> cur++;
> skipSpaces(&cur);
> if (!strncmp (cur, "no cpus", 7)) {
> nb_cpus = 0;
> for (cpu = 0;cpu < maxcpu;cpu++)
> cpuset[cpu] = 0;
> } else {
> nb_cpus = parseCpuSet(conn, &cur, 'n', cpuset, maxcpu);
>
>
Other than our discussion on #virt about handling of ^N specifications
in parseCpuSet, looks good!
Which is done in my version, will propagate.
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
11:33 a.m.
On Thu, Oct 18, 2007 at 04:53:15AM -0400, Daniel Veillard wrote:
On Wed, Oct 17, 2007 at 10:14:56PM -0400, beth kon wrote:
> This is certainly a nit, but I might change parseCpuNumber to
> parseNumber, since it looks a little odd that you are getting the cell
> id from the cpu number. A nit to be sure!
well, the only problem is if you have more cells than maxcpu,
which doesn't make that much sense. Since we are testing against
maxcpu I really think we should keep the function name, I can
duplicate code and make a simpler function just for parsing the
cell no.
> Other than our discussion on #virt about handling of ^N specifications
> in parseCpuSet, looks good!
Which is done in my version, will propagate.
New version with the changes suggested. Also the dump exercize the
serialization code ifor CPUset (see the new <dump> elements which won't
be used in the final code but useful to check correctness of output)
Valgrind tst allowed me to found a bug in virBufferContentAndFree()
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
3:02 a.m.
On Thu, 11 Oct 2007 09:00:14 -0400 Daniel Veillard wrote:
There are a few things I gathered on this issue. This affects
NUMA setups, where basically if a domain must be placed on a given cell
it is not good to let the hypervisor place it first with its own heuristics
and then later migrate it to a different set of CPU, but better to
instruct the hypervisor to start said domain on the given set.
That sounds good to me !
- For Xen it is possible to instruct the hypervisor by passing
(cpus '2,3') in the SExpr where the argument is a list of
the physical processors allowed
Yeah, we can set CPUs to the domain by passing that and
the physical CPUs will be pinned to VCPUs.
- for the mapping at the XML level I suggest to use a simple
extension
to the <vcpu>n</vcpu> and extend it to
<vcpu cpuset='2,3'>n</vcpu>
with a limited syntax which is just the comma separated list of
allowed CPU numbers (if the code actually detects such a cpuset is
in effect i.e. in general this won't be added).
How about adding <cpus>2,3</cpus> to the XML simply ?
And we may set 64 CPUs, it is hard to set all of them by each number.
(i.e. we have to set cpuset='1,2,3,4,5,6,7,8,9,10,....,64')
So I hope to use - (range) and ^ (negation) to set cpuset as Ryan said.
Regards,
Saori Fukuta
4:12 a.m.
On Fri, Oct 12, 2007 at 05:02:11PM +0900, Saori Fukuta wrote:
On Thu, 11 Oct 2007 09:00:14 -0400 Daniel Veillard wrote:
> - for the mapping at the XML level I suggest to use a simple extension
> to the <vcpu>n</vcpu> and extend it to
> <vcpu cpuset='2,3'>n</vcpu>
> with a limited syntax which is just the comma separated list of
> allowed CPU numbers (if the code actually detects such a cpuset is
> in effect i.e. in general this won't be added).
How about adding <cpus>2,3</cpus> to the XML simply ?
it's not any simpler. It's more complex because it adds a new element node
in the XML. Moreover I don't expect taht information to be any more structured
so it does not make sense to me to expose it as element content, plus
<cpus> could be used in the future to describe fully structured informations
so I don't think it makes sense to use it for just the cpuset.
And we may set 64 CPUs, it is hard to set all of them by each
number.
(i.e. we have to set cpuset='1,2,3,4,5,6,7,8,9,10,....,64')
So I hope to use - (range) and ^ (negation) to set cpuset as Ryan said.
On input why not. Do you have a complete description of the syntax
you want to allow ?
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
5:59 a.m.
On Fri, 12 Oct 2007 05:12:13 -0400 Daniel Veillard wrote:
On Fri, Oct 12, 2007 at 05:02:11PM +0900, Saori Fukuta wrote:
> On Thu, 11 Oct 2007 09:00:14 -0400 Daniel Veillard wrote:
> > - for the mapping at the XML level I suggest to use a simple extension
> > to the <vcpu>n</vcpu> and extend it to
> > <vcpu cpuset='2,3'>n</vcpu>
> > with a limited syntax which is just the comma separated list of
> > allowed CPU numbers (if the code actually detects such a cpuset is
> > in effect i.e. in general this won't be added).
>
> How about adding <cpus>2,3</cpus> to the XML simply ?
it's not any simpler. It's more complex because it adds a new element node
in the XML. Moreover I don't expect taht information to be any more structured
so it does not make sense to me to expose it as element content, plus
<cpus> could be used in the future to describe fully structured informations
so I don't think it makes sense to use it for just the cpuset.
Thanks for the explanation, I quoted the Xen-configuration (like cpus = "").
And that make sense to me !
> And we may set 64 CPUs, it is hard to set all of them by each
number.
> (i.e. we have to set cpuset='1,2,3,4,5,6,7,8,9,10,....,64')
> So I hope to use - (range) and ^ (negation) to set cpuset as Ryan said.
On input why not. Do you have a complete description of the syntax
you want to allow ?
Yeah, I was thinking about input. For output, your suggestion sounds
good. For input, I want to allow the following description of syntax.
(e.g.)
input : output
0 : 0
0-5 : 0,1,2,3,4,5
0-5,^1 : 0,2,3,4,5
0-3,5,^1 : 0,2,3,5
Regards,
Saori Fukuta
7:22 a.m.
On Fri, Oct 12, 2007 at 05:02:11PM +0900, Saori Fukuta wrote:
How about adding <cpus>2,3</cpus> to the XML simply ?
Just because the backends don't support strict binding of VCPUs to
particular CPUs I really don't think this should be encoded in the XML.
A strict binding is often the only sensible way to set things up.
regards
john
6244
days inactive
6251
days old
13 comments
6 participants
participants (6)
-
beth kon -
Daniel P. Berrange -
Daniel Veillard -
John Levon -
Ryan Harper -
Saori Fukuta