RE: [Xen-devel] [PATCH] xen, tools/python/xen: pincpu support vcpus, add vcpu to cpu map

["Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>]

 > > I see having this as a pre-requisite for any fancy new 
> scheduler (or 
> > as a first step, CPU load ballancer). Without it, I think it'll be 
> > scheduling anarchy :-)
> 
> OK.  Makes sense, that sounds like I separate patch.  I was thinking a
> u32 bitmap, but that doesn't give us the -1, run-anywhere.  
> Maybe EDF_USEPINMAP and a u32 bitmap.  if EDF_USEPINMAP is 
> set, then the balancer/scheduler looks at the bitmap to see 
> on which cpus the vcpu can run, if it is not set, the vcpu 
> can run anywhere.

We need to start incrementally introducing a cpu_set_t type that is a
suitably sized bit array. We can probably get away with 64 bits for 3.0,
but it might be more prudent to go for 256. We'll need to change the
hypercall interface to reflect this.

'-1' just sets all the bits to indicate that it can run anywhere. (If
you wanted to be really flash, you could enable an exclusion list to be
specified instead e.g. ^3,4,5 -- I like writing regexps so I'd probably
get carried away allowing wildcards to be specificed etc :-)

> > Yep, that's what I'm thinking. I think its probably worth squeezing 
> > out unsused levels of hierarchy, e.g. just having 
> SOCKET.THREAD in the 
> > above
> 
> OK.  I'll see how the implementation looks when I'm done.  It 
> sounds nice though.
> 
> > example. Keeping it pretty generic makes sense too. E.g. 
> imagine a big 
> > ccNUMA system with a 'node' level above that of the actual 
> CPU socket.
>  (
> Sure, I'll look at the Linux cpu groups stuff and the Linux 
> topology code to see if there is anything like this there.

Thanks. I think the correct thing to do is to pass a string from xm, and
do the conversion in xend. Xend should know the #hyperthreads, #cores,
#sockets, #nodes by reading it out of Xen. I think we can get away for
the moment with assuming that all CPUs are identical. 


Ian

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