[Libvir] [PATCH] finish NUMA code reorg, plug cpuset at creat time support

beth kon eak at us.ibm.com
Fri Nov 2 17:23:32 UTC 2007


Daniel Veillard wrote:

>On Wed, Oct 31, 2007 at 05:20:01PM +0900, Saori Fukuta wrote:
>  
>
>>On Tue, 30 Oct 2007 16:54:36 -0400 Daniel Veillard wrote:
>>    
>>
>>>  The associated patch compiles, but I have not yet tested it, it's 
>>>basically how I would expect to finish the NUMA work, but it certainly need
>>>debug and testing. I will look at this tomorrow, but I welcome feedback :-)
>>>      
>>>
>>sounds good to me, I tested with your patch, and I have four fixes for it.
>>    
>>
I tested with the latest code, and found a problem with specifying a 
value in the cpuset in XML that is greater than maxcpu-1. The attached 
patch corrects this behavior, but the issue remains that an out of range 
cpu will prevent the domain from starting. This is the way xm create 
works today.

In talking with Daniel about this, he made the point that it is not 
necessarily desirable for the failure of a tuning parameter (e.g., 
config specifies cpu 5 and the domain is now being started on a 4 cpu 
machine) to cause domain creation to fail. He mentioned phones ringing 
in the middle of the night somewhere for support when the domain fails 
to start. I think he has a point. Wouldn't it make more sense to start 
the domain(s) at perhaps suboptimal performance, than to have everything 
shut down until someone can come and figure out the problem?

It would seem better if the domain started (with no cpu affinity) and a 
warning was posted. This might also argue for separation of domain 
config and tuning parameters. Or at least for 2 flavors of create? One 
that fails if tuning parameters cannot be activated, and one that doesn't.



-- 
Elizabeth Kon (Beth)
IBM Linux Technology Center
Open Hypervisor Team
email: eak at us.ibm.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: cpuset.patch
Type: text/x-patch
Size: 732 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20071102/473ff8a9/attachment-0001.bin>


More information about the libvir-list mailing list