WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: "Ryan Harper" <ryanh@xxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH] xen, tools/python/xen: pincpu support vcpus, add vcpu to cpu map
From: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>
Date: Thu, 14 Apr 2005 19:28:31 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 14 Apr 2005 18:28:20 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcVBGUv2QLuclnUARISTPPphsvH3/AAAsTNw
Thread-topic: [Xen-devel] [PATCH] xen, tools/python/xen: pincpu support vcpus, add vcpu to cpu map
 > > 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