[Libvir] CPU pinning of domains at creation time

[Daniel Veillard]

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 at 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 at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/