Discussion VM CPU pinning and NUMA CPU pinning
</o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-family:"HP S= implified","sans-serif""> = ; Broker: <o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"text-indent:21.0pt"><span lang=3D"EN-US" st= yle=3D"font-family:"HP Simplified","sans-serif"">Remove= temporary solution(See the current implementation as below) and follow pre= vious cpupin configuration procedure.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-family:"HP S= implified","sans-serif""><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-family:"HP S= implified","sans-serif"">Solution 2:<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-family:"HP S= implified","sans-serif""> = ; GUI: <span style=3D"color:#FFC000"><o:p></o:p></span></span></p> <p class=3D"MsoNormal" style=3D"margin-left:19.4pt"><span lang=3D"EN-US" st= yle=3D"font-family:"HP Simplified","sans-serif"">If cur= rent VM CPU pinning is configured, when user open NUMA CPU pinning configur= e page, he will get a warning message. If he continues to configure NUMA CPU pinning and save the data, the current VM CPU pinning = ; configuration will be cleared.<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"text-indent:19.4pt"><span lang=3D"EN-US" st= yle=3D"font-family:"HP Simplified","sans-serif"">NUMA C= PU pinning configured data will be saved as new structure individually with= out changing current VM CPU pinning configuration.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-family:"HP S= implified","sans-serif""> = ; Restful: <span style=3D"color:#FFC000"><o:p></o:p></span></span></p> <p class=3D"MsoNormal" style=3D"text-indent:21.0pt"><span lang=3D"EN-US" st= yle=3D"font-family:"HP Simplified","sans-serif"">Config= ure NUMA CPU pinning and then save the data with the new NUMA CPU pinning s=
--_000_B63C858E777679458338A30A991BB5240163BDA8G2W2441americas_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, Now we are working on the NUMA tune feature development for oVirt 3.5. This= feature allow user to configure the vCPU pining according to host CPU/NUMA= topology to get the best performance for created VM. But this will impact = the current function of vCPU pining. Now, we are looking for a solution to = consolidate the conflict. We want to start an open discussion about VM CPU = pinning (the current design) and NUMA CPU pining (new feature we are workin= g on) in developer list: Background: Concept: 1. VM CPU pinning: the exist feature in current oVirt, which allow use= r to configure the VM vCPU pinning over ovirt, user can configure vCPU pini= ng independently without NUMA tune. 2. NUMA CPU pinning: allow user to configure the vCPU pining according= to host NUMA topology to get the best performance for created VM 3. vNode: Virtual NUMA node ( User configured ) 4. pNode: host physical NUMA node ( Get capability from host ) Notice: 1. NUMA tuning feature and CPU pinning feature are individually in lib= virt ( ovirt backend ). 2. User could configure VM CPU pining individually without NUMA tune s= etup. 3. When configuring NUMA tuning feature, user need to configure VM NUM= A tuning ( vNode pinto pNode & tuning mode ) and VM CPU pinning ( NUMA incl= uded ) to get optimized VM performance, otherwise VM will have low performa= nce. We have two proposal now for this issue. Please give us some comments and y= our feedback, thanks. Solution 1: GUI: Transform between the CPU pinning text and a structure which will be used i= n NUMA CPU pinning configure page. And then save the CPU pinning text to the current VM CPU pinning field = of VM. Restful: Transform between the CPU pinning text and a structure which will be used i= n restful NUMA CPU pinning. And then save the CPU pinning text to the current VM CPU pinning field of V= M. Broker: Remove temporary solution(See the current implementation as below) and foll= ow previous cpupin configuration procedure. Solution 2: GUI: If current VM CPU pinning is configured, when user open NUMA CPU pinning co= nfigure page, he will get a warning message. If he continues to configure N= UMA CPU pinning and save the data, the current VM CPU pinning configura= tion will be cleared. NUMA CPU pinning configured data will be saved as new structure individuall= y without changing current VM CPU pinning configuration. Restful: Configure NUMA CPU pinning and then save the data with the new NUMA CPU pin= ning structure. Entity and Database: Individually NUMA CPU pinning entities and data structure. Broker: NUMA CPU pinning configuration will be first considered to use. If= it's not configured, it will use the current VM CPU pinning. Solution 1 The CPU pining data is consistent but the code logic is very com= plex. Solution 2 have better adaptive and better data structure. This is the way = we preferred. We are appreciated that anybody could give us your comments or the better s= olution you have. The below is the current implementation for your reference: VM CPU pinning feature GUI: User input vCPU pining configure data with formatted text. Restful: User configure CpuTune and VCpuPin model with mapper to CPU pinning text. Entity and Database: CPU pinning is String property. Broker: Generate structure of cputune ( libvirt format ) from CPU pining string pro= perty. NUMA tuning feature GUI: User can drag & drop virtual NUMA node to host NUMA node ( pin to or remove= pin to ). Restful: Add/update/remove virtual NUMA node with property of pin to host NUMA node = index. Design NUMACPU model under NUMA node for extend. Entity and Database: Individually NUMA node entities ( vNode extend pNode ) and store procedure. Broker: Generate structure of numatune, cpu/numa ( libvirt format ) from NUMA node = entities. Temporary solution prevent Notice 3 Broker: Generate right structure of cputune ( libivirt format ) from NUMA node enti= ties ( vNode pinto pNode ) Limitation: This structure of cputune will not get the best performance of vNode. Best Regards, Jason Liao --_000_B63C858E777679458338A30A991BB5240163BDA8G2W2441americas_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 1"> <meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)"> <style><!-- /* Font Definitions */ @font-face {font-family:SimSun; panose-1:2 1 6 0 3 1 1 1 1 1;} @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:"HP Simplified"; panose-1:2 11 6 4 2 2 4 2 2 4;} @font-face {font-family:"YaHei Consolas Hybrid"; panose-1:2 11 5 9 2 2 4 2 2 4;} @font-face {font-family:SimSun; panose-1:2 1 6 0 3 1 1 1 1 1;} @font-face {font-family:"\@YaHei Consolas Hybrid"; panose-1:2 11 5 9 2 2 4 2 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0cm; margin-bottom:.0001pt; text-align:justify; text-justify:inter-ideograph; font-size:10.5pt; font-family:"Calibri","sans-serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:#0563C1; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:#954F72; text-decoration:underline;} p.MsoPlainText, li.MsoPlainText, div.MsoPlainText {mso-style-priority:99; mso-style-link:"Plain Text Char"; margin:0cm; margin-bottom:.0001pt; font-size:10.5pt; font-family:"HP Simplified","sans-serif";} p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {mso-style-priority:34; margin:0cm; margin-bottom:.0001pt; text-align:justify; text-justify:inter-ideograph; text-indent:21.0pt; font-size:10.5pt; font-family:"Calibri","sans-serif";} span.EmailStyle17 {mso-style-type:personal-compose; font-family:"HP Simplified","sans-serif"; color:windowtext;} span.PlainTextChar {mso-style-name:"Plain Text Char"; mso-style-priority:99; mso-style-link:"Plain Text"; font-family:"HP Simplified","sans-serif";} .MsoChpDefault {mso-style-type:export-only;} /* Page Definitions */ @page WordSection1 {size:612.0pt 792.0pt; margin:72.0pt 90.0pt 72.0pt 90.0pt;} div.WordSection1 {page:WordSection1;} /* List Definitions */ @list l0 {mso-list-id:1440225503; mso-list-type:hybrid; mso-list-template-ids:-598169600 1424391416 67698713 67698715 67698703 676= 98713 67698715 67698703 67698713 67698715;} @list l0:level1 {mso-level-tab-stop:none; mso-level-number-position:left; margin-left:18.0pt; text-indent:-18.0pt;} @list l0:level2 {mso-level-number-format:alpha-lower; mso-level-text:"%2\)"; mso-level-tab-stop:none; mso-level-number-position:left; margin-left:42.0pt; text-indent:-21.0pt;} @list l0:level3 {mso-level-number-format:roman-lower; mso-level-tab-stop:none; mso-level-number-position:right; margin-left:63.0pt; text-indent:-21.0pt;} @list l0:level4 {mso-level-tab-stop:none; mso-level-number-position:left; margin-left:84.0pt; text-indent:-21.0pt;} @list l0:level5 {mso-level-number-format:alpha-lower; mso-level-text:"%5\)"; mso-level-tab-stop:none; mso-level-number-position:left; margin-left:105.0pt; text-indent:-21.0pt;} @list l0:level6 {mso-level-number-format:roman-lower; mso-level-tab-stop:none; mso-level-number-position:right; margin-left:126.0pt; text-indent:-21.0pt;} @list l0:level7 {mso-level-tab-stop:none; mso-level-number-position:left; margin-left:147.0pt; text-indent:-21.0pt;} @list l0:level8 {mso-level-number-format:alpha-lower; mso-level-text:"%8\)"; mso-level-tab-stop:none; mso-level-number-position:left; margin-left:168.0pt; text-indent:-21.0pt;} @list l0:level9 {mso-level-number-format:roman-lower; mso-level-tab-stop:none; mso-level-number-position:right; margin-left:189.0pt; text-indent:-21.0pt;} @list l1 {mso-list-id:2059089049; mso-list-type:hybrid; mso-list-template-ids:148561564 103326546 67698713 67698715 67698703 67698= 713 67698715 67698703 67698713 67698715;} @list l1:level1 {mso-level-tab-stop:none; mso-level-number-position:left; margin-left:18.0pt; text-indent:-18.0pt; mso-fareast-font-family:SimSun;} @list l1:level2 {mso-level-number-format:alpha-lower; mso-level-text:"%2\)"; mso-level-tab-stop:none; mso-level-number-position:left; margin-left:42.0pt; text-indent:-21.0pt;} @list l1:level3 {mso-level-number-format:roman-lower; mso-level-tab-stop:none; mso-level-number-position:right; margin-left:63.0pt; text-indent:-21.0pt;} @list l1:level4 {mso-level-tab-stop:none; mso-level-number-position:left; margin-left:84.0pt; text-indent:-21.0pt;} @list l1:level5 {mso-level-number-format:alpha-lower; mso-level-text:"%5\)"; mso-level-tab-stop:none; mso-level-number-position:left; margin-left:105.0pt; text-indent:-21.0pt;} @list l1:level6 {mso-level-number-format:roman-lower; mso-level-tab-stop:none; mso-level-number-position:right; margin-left:126.0pt; text-indent:-21.0pt;} @list l1:level7 {mso-level-tab-stop:none; mso-level-number-position:left; margin-left:147.0pt; text-indent:-21.0pt;} @list l1:level8 {mso-level-number-format:alpha-lower; mso-level-text:"%8\)"; mso-level-tab-stop:none; mso-level-number-position:left; margin-left:168.0pt; text-indent:-21.0pt;} @list l1:level9 {mso-level-number-format:roman-lower; mso-level-tab-stop:none; mso-level-number-position:right; margin-left:189.0pt; text-indent:-21.0pt;} ol {margin-bottom:0cm;} ul {margin-bottom:0cm;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3D"ZH-CN" link=3D"#0563C1" vlink=3D"#954F72" style=3D"text-justi= fy-trim:punctuation"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-family:"HP S= implified","sans-serif"">Hi All,<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-family:"HP S= implified","sans-serif""><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-family:"HP S= implified","sans-serif"">Now we are working on the NUMA tune= feature development for oVirt 3.5. This feature allow user to configure th= e vCPU pining according to host CPU/NUMA topology to get the best performance for created VM. But this will impact the current function= of vCPU pining. Now, we are looking for a solution to consolidate the conf= lict. We want to start an open discussion about VM CPU pinning (the current= design) and NUMA CPU pining (new feature we are working on) in developer list:<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-family:"HP S= implified","sans-serif""><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-family:"HP S= implified","sans-serif"">Background:<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-family:"HP S= implified","sans-serif"">Concept:<o:p></o:p></span></p> <p class=3D"MsoListParagraph" style=3D"margin-left:18.0pt;text-indent:-18.0= pt;mso-list:l1 level1 lfo1"> <![if !supportLists]><span lang=3D"EN-US" style=3D"font-family:"HP Sim= plified","sans-serif""><span style=3D"mso-list:Ignore">1.<sp= an style=3D"font:7.0pt "Times New Roman""> = ; </span></span></span><![endif]><span lang=3D"EN-US" style=3D"font-family:&q= uot;HP Simplified","sans-serif"">VM CPU pinning: the exist f= eature in current oVirt, which allow user to configure the VM vCPU pinning = over ovirt, user can configure vCPU pining independently without NUMA tune.<o:p></o:p></span></p> <p class=3D"MsoListParagraph" style=3D"margin-left:18.0pt;text-indent:-18.0= pt;mso-list:l1 level1 lfo1"> <![if !supportLists]><span lang=3D"EN-US" style=3D"font-family:"HP Sim= plified","sans-serif""><span style=3D"mso-list:Ignore">2.<sp= an style=3D"font:7.0pt "Times New Roman""> = ; </span></span></span><![endif]><span lang=3D"EN-US" style=3D"font-family:&q= uot;HP Simplified","sans-serif"">NUMA CPU pinning: allow use= r to configure the vCPU pining according to host NUMA topology to get the b= est performance for created VM<o:p></o:p></span></p> <p class=3D"MsoListParagraph" style=3D"margin-left:18.0pt;text-indent:-18.0= pt;mso-list:l1 level1 lfo1"> <![if !supportLists]><span lang=3D"EN-US" style=3D"font-family:"HP Sim= plified","sans-serif""><span style=3D"mso-list:Ignore">3.<sp= an style=3D"font:7.0pt "Times New Roman""> = ; </span></span></span><![endif]><span lang=3D"EN-US" style=3D"font-family:&q= uot;HP Simplified","sans-serif"">vNode: Virtual NUMA node ( = User configured )<o:p></o:p></span></p> <p class=3D"MsoListParagraph" style=3D"margin-left:18.0pt;text-indent:-18.0= pt;mso-list:l1 level1 lfo1"> <![if !supportLists]><span lang=3D"EN-US" style=3D"font-family:"HP Sim= plified","sans-serif""><span style=3D"mso-list:Ignore">4.<sp= an style=3D"font:7.0pt "Times New Roman""> = ; </span></span></span><![endif]><span lang=3D"EN-US" style=3D"font-family:&q= uot;HP Simplified","sans-serif"">pNode: host physical NUMA n= ode ( Get capability from host )<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-family:"HP S= implified","sans-serif"">Notice:<o:p></o:p></span></p> <p class=3D"MsoPlainText" style=3D"margin-left:18.0pt;text-align:justify;te= xt-justify:inter-ideograph;text-indent:-18.0pt;mso-list:l0 level1 lfo2"> <![if !supportLists]><span lang=3D"EN-US"><span style=3D"mso-list:Ignore">1= .<span style=3D"font:7.0pt "Times New Roman""> &= nbsp; </span></span></span><![endif]><span lang=3D"EN-US">NUMA tuning feature and= CPU pinning feature are individually in libvirt ( ovirt backend ).<o:p></o= :p></span></p> <p class=3D"MsoPlainText" style=3D"margin-left:18.0pt;text-indent:-18.0pt;m= so-list:l0 level1 lfo2"> <![if !supportLists]><span lang=3D"EN-US"><span style=3D"mso-list:Ignore">2= .<span style=3D"font:7.0pt "Times New Roman""> &= nbsp; </span></span></span><![endif]><span lang=3D"EN-US">User could configure VM= CPU pining individually without NUMA tune setup.<o:p></o:p></span></p> <p class=3D"MsoPlainText" style=3D"margin-left:18.0pt;text-align:justify;te= xt-justify:inter-ideograph;text-indent:-18.0pt;mso-list:l0 level1 lfo2"> <![if !supportLists]><span lang=3D"EN-US"><span style=3D"mso-list:Ignore">3= .<span style=3D"font:7.0pt "Times New Roman""> &= nbsp; </span></span></span><![endif]><span lang=3D"EN-US">When configuring NUMA t= uning feature, user need to configure VM NUMA tuning ( vNode pinto pNode &a= mp; tuning mode ) and VM CPU pinning ( NUMA included ) to get optimized VM = performance, otherwise VM will have low performance.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-family:"HP S= implified","sans-serif""><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-family:"HP S= implified","sans-serif"">We have two proposal now for this i= ssue. Please give us some comments and your feedback, thanks.<o:p></o:p></s= pan></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-family:"HP S= implified","sans-serif""><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-family:"HP S= implified","sans-serif"">Solution 1:<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-family:"HP S= implified","sans-serif""> = ; GUI: <o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"text-indent:21.0pt"><span lang=3D"EN-US" st= yle=3D"font-family:"HP Simplified","sans-serif"">Transf= orm between the CPU pinning text and a structure which will be used in NUMA= CPU pinning configure page.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-family:"HP S= implified","sans-serif""> And then save th= e CPU pinning text to the current VM CPU pinning field of VM. <o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-family:"HP S= implified","sans-serif""> = ; Restful: <o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"text-indent:21.0pt"><span lang=3D"EN-US" st= yle=3D"font-family:"HP Simplified","sans-serif"">Transf= orm between the CPU pinning text and a structure which will be used in rest= ful NUMA CPU pinning.<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"text-indent:21.0pt"><span lang=3D"EN-US" st= yle=3D"font-family:"HP Simplified","sans-serif"">And th= en save the CPU pinning text to the current VM CPU pinning field of VM.<o:p= tructure. <o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-family:"HP S= implified","sans-serif""> = ; Entity and Database: <o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"text-indent:21.0pt"><span lang=3D"EN-US" st= yle=3D"font-family:"HP Simplified","sans-serif"">Indivi= dually NUMA CPU pinning entities and data structure.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-family:"HP S= implified","sans-serif""> = ; Broker: <span style=3D"color:#FFC000"><o:p></o:p></span></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-family:"HP S= implified","sans-serif";color:#FFC000"> &nb= sp; </span><span lang=3D"EN-US" style=3D"font-family:"HP Simplified",= "sans-serif"">NUMA CPU pinning configuration will be first consid= ered to use. If it’s not configured, it will use the current VM CPU p= inning.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-family:"HP S= implified","sans-serif""><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-family:"HP S= implified","sans-serif"">Solution 1 The CPU pining data is c= onsistent but the code logic is very complex.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-family:"HP S= implified","sans-serif"">Solution 2 have better adaptive and= better data structure. This is the way we preferred.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-family:"HP S= implified","sans-serif""><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-family:"HP S= implified","sans-serif"">We are appreciated that anybody cou= ld give us your comments or the better solution you have.<o:p></o:p></span>= </p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-family:"HP S= implified","sans-serif""><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-family:"HP S= implified","sans-serif""><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-family:"HP S= implified","sans-serif""><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-family:"HP S= implified","sans-serif"">The below is the current implementa= tion for your reference:<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-family:"HP S= implified","sans-serif"">VM CPU pinning feature<o:p></o:p></= span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-family:"HP S= implified","sans-serif""> = ; GUI: <o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"text-indent:21.0pt"><span lang=3D"EN-US" st= yle=3D"font-family:"HP Simplified","sans-serif"">User i= nput vCPU pining configure data with formatted text.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-family:"HP S= implified","sans-serif""> = ; Restful: <o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"text-indent:21.0pt"><span lang=3D"EN-US" st= yle=3D"font-family:"HP Simplified","sans-serif"">User c= onfigure CpuTune and VCpuPin model with mapper to CPU pinning text.<o:p></o= :p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-family:"HP S= implified","sans-serif""> = ; Entity and Database: <o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"text-indent:21.0pt"><span lang=3D"EN-US" st= yle=3D"font-family:"HP Simplified","sans-serif"">CPU pi= nning is String property.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-family:"HP S= implified","sans-serif""> = ; Broker: <o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"text-indent:21.0pt"><span lang=3D"EN-US" st= yle=3D"font-family:"HP Simplified","sans-serif"">Genera= te structure of cputune ( libvirt format ) from CPU pining string property.= <o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-family:"HP S= implified","sans-serif"">NUMA tuning feature<o:p></o:p></spa= n></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-family:"HP S= implified","sans-serif""> = ; GUI: <o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"text-indent:21.0pt"><span lang=3D"EN-US" st= yle=3D"font-family:"HP Simplified","sans-serif"">User c= an drag & drop virtual NUMA node to host NUMA node ( pin to or remove p= in to ).<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-family:"HP S= implified","sans-serif""> = ; Restful: <o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"text-indent:21.0pt"><span lang=3D"EN-US" st= yle=3D"font-family:"HP Simplified","sans-serif"">Add/up= date/remove virtual NUMA node with property of pin to host NUMA node index.= <o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-family:"HP S= implified","sans-serif""> = ; Design NUMACPU model under NUMA node for extend.<o:p></o:p></= span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-family:"HP S= implified","sans-serif""> = ; Entity and Database: <o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"text-indent:21.0pt"><span lang=3D"EN-US" st= yle=3D"font-family:"HP Simplified","sans-serif"">Indivi= dually NUMA node entities ( vNode extend pNode ) and store procedure.<o:p><= /o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-family:"HP S= implified","sans-serif""> = ; Broker: <o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"text-indent:21.0pt"><span lang=3D"EN-US" st= yle=3D"font-family:"HP Simplified","sans-serif"">Genera= te structure of numatune, cpu/numa ( libvirt format ) from NUMA node entiti= es.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-family:"HP S= implified","sans-serif"">Temporary solution prevent Notice 3= <o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-family:"HP S= implified","sans-serif""> = ; Broker: <o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"text-indent:21.0pt"><span lang=3D"EN-US" st= yle=3D"font-family:"HP Simplified","sans-serif"">Genera= te right structure of cputune ( libivirt format ) from NUMA node entities (= vNode pinto pNode )<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-family:"HP S= implified","sans-serif""> = ; Limitation: <o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"text-indent:21.0pt"><span lang=3D"EN-US" st= yle=3D"font-family:"HP Simplified","sans-serif"">This s= tructure of cputune will not get the best performance of vNode.<o:p></o:p><= /span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-family:"HP S= implified","sans-serif""><o:p> </o:p></span></p> <p class=3D"MsoNormal"><b><span lang=3D"EN-US" style=3D"font-size:9.0pt;fon= t-family:"HP Simplified","sans-serif";color:black">Best= Regards,<br> </span></b><span lang=3D"EN-US" style=3D"font-size:9.0pt;font-family:"= HP Simplified","sans-serif";color:#717172">Jason Liao</span>= <span lang=3D"EN-US" style=3D"font-family:"HP Simplified","s= ans-serif""><o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-family:"HP S= implified","sans-serif""><o:p> </o:p></span></p> </div> </body> </html> --_000_B63C858E777679458338A30A991BB5240163BDA8G2W2441americas_--
Can you please be more specific on how to model RESTful API, with regards to CPU and CPU-pinning. Thanks, Gilad. ----- Original Message -----
From: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao@hp.com> To: devel@ovirt.org Cc: "Doron Fediuck" <dfediuck@redhat.com>, "Gilad Chaplik" <gchaplik@redhat.com>, "Martin Sivák" <msivak@redhat.com>, "Juan Hernandez" <juan.hernandez@redhat.com>, "Malini Rao" <mrao@redhat.com>, "Chegu Vinod" <chegu_vinod@hp.com>, "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)" <shangchun.liang@hp.com>, "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi@hp.com> Sent: Thursday, May 15, 2014 2:50:23 PM Subject: Discussion VM CPU pinning and NUMA CPU pinning
Hi All,
Now we are working on the NUMA tune feature development for oVirt 3.5. This feature allow user to configure the vCPU pining according to host CPU/NUMA topology to get the best performance for created VM. But this will impact the current function of vCPU pining. Now, we are looking for a solution to consolidate the conflict. We want to start an open discussion about VM CPU pinning (the current design) and NUMA CPU pining (new feature we are working on) in developer list:
Background: Concept:
1. VM CPU pinning: the exist feature in current oVirt, which allow user to configure the VM vCPU pinning over ovirt, user can configure vCPU pining independently without NUMA tune.
2. NUMA CPU pinning: allow user to configure the vCPU pining according to host NUMA topology to get the best performance for created VM
3. vNode: Virtual NUMA node ( User configured )
4. pNode: host physical NUMA node ( Get capability from host ) Notice:
1. NUMA tuning feature and CPU pinning feature are individually in libvirt ( ovirt backend ).
2. User could configure VM CPU pining individually without NUMA tune setup.
3. When configuring NUMA tuning feature, user need to configure VM NUMA tuning ( vNode pinto pNode & tuning mode ) and VM CPU pinning ( NUMA included ) to get optimized VM performance, otherwise VM will have low performance.
We have two proposal now for this issue. Please give us some comments and your feedback, thanks.
Solution 1: GUI: Transform between the CPU pinning text and a structure which will be used in NUMA CPU pinning configure page. And then save the CPU pinning text to the current VM CPU pinning field of VM. Restful: Transform between the CPU pinning text and a structure which will be used in restful NUMA CPU pinning. And then save the CPU pinning text to the current VM CPU pinning field of VM. Broker: Remove temporary solution(See the current implementation as below) and follow previous cpupin configuration procedure.
Solution 2: GUI: If current VM CPU pinning is configured, when user open NUMA CPU pinning configure page, he will get a warning message. If he continues to configure NUMA CPU pinning and save the data, the current VM CPU pinning configuration will be cleared. NUMA CPU pinning configured data will be saved as new structure individually without changing current VM CPU pinning configuration. Restful: Configure NUMA CPU pinning and then save the data with the new NUMA CPU pinning structure. Entity and Database: Individually NUMA CPU pinning entities and data structure. Broker: NUMA CPU pinning configuration will be first considered to use. If it's not configured, it will use the current VM CPU pinning.
Solution 1 The CPU pining data is consistent but the code logic is very complex. Solution 2 have better adaptive and better data structure. This is the way we preferred.
We are appreciated that anybody could give us your comments or the better solution you have.
The below is the current implementation for your reference: VM CPU pinning feature GUI: User input vCPU pining configure data with formatted text. Restful: User configure CpuTune and VCpuPin model with mapper to CPU pinning text. Entity and Database: CPU pinning is String property. Broker: Generate structure of cputune ( libvirt format ) from CPU pining string property. NUMA tuning feature GUI: User can drag & drop virtual NUMA node to host NUMA node ( pin to or remove pin to ). Restful: Add/update/remove virtual NUMA node with property of pin to host NUMA node index. Design NUMACPU model under NUMA node for extend. Entity and Database: Individually NUMA node entities ( vNode extend pNode ) and store procedure. Broker: Generate structure of numatune, cpu/numa ( libvirt format ) from NUMA node entities. Temporary solution prevent Notice 3 Broker: Generate right structure of cputune ( libivirt format ) from NUMA node entities ( vNode pinto pNode ) Limitation: This structure of cputune will not get the best performance of vNode.
Best Regards, Jason Liao
Hi Gilad, Thanks for your reply. Did you submit the UI code. We need to know your UI model to consolidate your feedback. Meanwhile, we need to know the current cpu pining solution that include the UI code you are in charging. Then, we will see if we can specific to RESTful. Best Regards, David Liang
-----Original Message----- From: Gilad Chaplik [mailto:gchaplik@redhat.com] Sent: Thursday, May 15, 2014 8:07 PM To: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC) Cc: devel@ovirt.org; Doron Fediuck; Martin Sivák; Juan Hernandez; Malini Rao; Vinod, Chegu; Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC); Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ) Subject: Re: Discussion VM CPU pinning and NUMA CPU pinning
Can you please be more specific on how to model RESTful API, with regards to CPU and CPU-pinning.
Thanks, Gilad.
From: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao@hp.com> To: devel@ovirt.org Cc: "Doron Fediuck" <dfediuck@redhat.com>, "Gilad Chaplik" <gchaplik@redhat.com>, "Martin Sivák" <msivak@redhat.com>, "Juan Hernandez" <juan.hernandez@redhat.com>, "Malini Rao" <mrao@redhat.com>, "Chegu Vinod" <chegu_vinod@hp.com>, "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)" <shangchun.liang@hp.com>, "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi@hp.com> Sent: Thursday, May 15, 2014 2:50:23 PM Subject: Discussion VM CPU pinning and NUMA CPU pinning
Hi All,
Now we are working on the NUMA tune feature development for oVirt 3.5. This feature allow user to configure the vCPU pining according to host CPU/NUMA topology to get the best performance for created VM. But this will impact the current function of vCPU pining. Now, we are looking for a solution to consolidate the conflict. We want to start an open discussion about VM CPU pinning (the current design) and NUMA CPU pining (new feature we are working on) in developer list:
Background: Concept:
1. VM CPU pinning: the exist feature in current oVirt, which allow user to configure the VM vCPU pinning over ovirt, user can configure vCPU
independently without NUMA tune.
2. NUMA CPU pinning: allow user to configure the vCPU pining according to host NUMA topology to get the best performance for created VM
3. vNode: Virtual NUMA node ( User configured )
4. pNode: host physical NUMA node ( Get capability from host ) Notice:
1. NUMA tuning feature and CPU pinning feature are individually in libvirt ( ovirt backend ).
2. User could configure VM CPU pining individually without NUMA tune setup.
3. When configuring NUMA tuning feature, user need to configure VM NUMA tuning ( vNode pinto pNode & tuning mode ) and VM CPU pinning ( NUMA included ) to get optimized VM performance, otherwise VM will have low performance.
We have two proposal now for this issue. Please give us some comments and your feedback, thanks.
Solution 1: GUI: Transform between the CPU pinning text and a structure which will be used in NUMA CPU pinning configure page. And then save the CPU pinning text to the current VM CPU pinning field of VM. Restful: Transform between the CPU pinning text and a structure which will be used in restful NUMA CPU pinning. And then save the CPU pinning text to the current VM CPU pinning field of VM. Broker: Remove temporary solution(See the current implementation as below) and follow previous cpupin configuration procedure.
Solution 2: GUI: If current VM CPU pinning is configured, when user open NUMA CPU
configure page, he will get a warning message. If he continues to configure NUMA CPU pinning and save the data, the current VM CPU pinning configuration will be cleared. NUMA CPU pinning configured data will be saved as new structure individually without changing current VM CPU pinning configuration. Restful: Configure NUMA CPU pinning and then save the data with the new NUMA CPU pinning structure. Entity and Database: Individually NUMA CPU pinning entities and data structure. Broker: NUMA CPU pinning configuration will be first considered to use. If it's not configured, it will use the current VM CPU pinning.
Solution 1 The CPU pining data is consistent but the code logic is very complex. Solution 2 have better adaptive and better data structure. This is the way we preferred.
We are appreciated that anybody could give us your comments or the better solution you have.
The below is the current implementation for your reference: VM CPU pinning feature GUI: User input vCPU pining configure data with formatted text. Restful: User configure CpuTune and VCpuPin model with mapper to CPU pinning text. Entity and Database: CPU pinning is String property. Broker: Generate structure of cputune ( libvirt format ) from CPU pining string property. NUMA tuning feature GUI: User can drag & drop virtual NUMA node to host NUMA node ( pin to or remove pin to ). Restful: Add/update/remove virtual NUMA node with property of pin to host NUMA node index. Design NUMACPU model under NUMA node for extend. Entity and Database: Individually NUMA node entities ( vNode extend pNode ) and store
----- Original Message ----- pining pinning procedure.
Broker: Generate structure of numatune, cpu/numa ( libvirt format ) from NUMA
node
entities. Temporary solution prevent Notice 3 Broker: Generate right structure of cputune ( libivirt format ) from NUMA node entities ( vNode pinto pNode ) Limitation: This structure of cputune will not get the best performance of vNode.
Best Regards, Jason Liao
Hi Gilad, The restful API model of NUMA CPU and CPU-pinning is named NUMACPU ( Under NumaNode, VirutalNumaNode ) Which is contain some attributes; index (xs:int): Numa CPU index or vNuma CPU index. pin_set (xs:string): Virtual NUMA CPU pin to host NUMA CPU set. ( only enabled on VirtualNumaNode ) BTW, Could you give us some update about UI layer solution of NUMA CPU-pinning configuration ? Best Regards, Jason Liao
-----Original Message----- From: Gilad Chaplik [mailto:gchaplik@redhat.com] Sent: 2014年5月15日 20:07 To: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC) Cc: devel@ovirt.org; Doron Fediuck; Martin Sivák; Juan Hernandez; Malini Rao; Vinod, Chegu; Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC); Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ) Subject: Re: Discussion VM CPU pinning and NUMA CPU pinning
Can you please be more specific on how to model RESTful API, with regards to CPU and CPU-pinning.
Thanks, Gilad.
----- Original Message -----
From: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao@hp.com> To: devel@ovirt.org Cc: "Doron Fediuck" <dfediuck@redhat.com>, "Gilad Chaplik" <gchaplik@redhat.com>, "Martin Sivák" <msivak@redhat.com>, "Juan Hernandez" <juan.hernandez@redhat.com>, "Malini Rao" <mrao@redhat.com>, "Chegu Vinod" <chegu_vinod@hp.com>, "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)" <shangchun.liang@hp.com>, "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi@hp.com> Sent: Thursday, May 15, 2014 2:50:23 PM Subject: Discussion VM CPU pinning and NUMA CPU pinning
Hi All,
Now we are working on the NUMA tune feature development for oVirt 3.5. This feature allow user to configure the vCPU pining according to host CPU/NUMA topology to get the best performance for created VM. But this will impact the current function of vCPU pining. Now, we are looking for a solution to consolidate the conflict. We want to start an open discussion about VM CPU pinning (the current design) and NUMA CPU pining (new feature we are working on) in developer list:
Background: Concept:
1. VM CPU pinning: the exist feature in current oVirt, which allow user to configure the VM vCPU pinning over ovirt, user can configure vCPU pining independently without NUMA tune.
2. NUMA CPU pinning: allow user to configure the vCPU pining according to host NUMA topology to get the best performance for created VM
3. vNode: Virtual NUMA node ( User configured )
4. pNode: host physical NUMA node ( Get capability from host ) Notice:
1. NUMA tuning feature and CPU pinning feature are individually in libvirt ( ovirt backend ).
2. User could configure VM CPU pining individually without NUMA tune setup.
3. When configuring NUMA tuning feature, user need to configure VM NUMA tuning ( vNode pinto pNode & tuning mode ) and VM CPU pinning ( NUMA included ) to get optimized VM performance, otherwise VM will have low performance.
We have two proposal now for this issue. Please give us some comments and your feedback, thanks.
Solution 1: GUI: Transform between the CPU pinning text and a structure which will be used in NUMA CPU pinning configure page. And then save the CPU pinning text to the current VM CPU pinning field of VM. Restful: Transform between the CPU pinning text and a structure which will be used in restful NUMA CPU pinning. And then save the CPU pinning text to the current VM CPU pinning field of VM. Broker: Remove temporary solution(See the current implementation as below) and follow previous cpupin configuration procedure.
Solution 2: GUI: If current VM CPU pinning is configured, when user open NUMA CPU pinning configure page, he will get a warning message. If he continues to configure NUMA CPU pinning and save the data, the current VM CPU pinning configuration will be cleared. NUMA CPU pinning configured data will be saved as new structure individually without changing current VM CPU pinning configuration. Restful: Configure NUMA CPU pinning and then save the data with the new NUMA CPU pinning structure. Entity and Database: Individually NUMA CPU pinning entities and data structure. Broker: NUMA CPU pinning configuration will be first considered to use. If it's not configured, it will use the current VM CPU pinning.
Solution 1 The CPU pining data is consistent but the code logic is very complex. Solution 2 have better adaptive and better data structure. This is the way we preferred.
We are appreciated that anybody could give us your comments or the better solution you have.
The below is the current implementation for your reference: VM CPU pinning feature GUI: User input vCPU pining configure data with formatted text. Restful: User configure CpuTune and VCpuPin model with mapper to CPU pinning text. Entity and Database: CPU pinning is String property. Broker: Generate structure of cputune ( libvirt format ) from CPU pining string property. NUMA tuning feature GUI: User can drag & drop virtual NUMA node to host NUMA node ( pin to or remove pin to ). Restful: Add/update/remove virtual NUMA node with property of pin to host NUMA node index. Design NUMACPU model under NUMA node for extend. Entity and Database: Individually NUMA node entities ( vNode extend pNode ) and store procedure. Broker: Generate structure of numatune, cpu/numa ( libvirt format ) from NUMA node entities. Temporary solution prevent Notice 3 Broker: Generate right structure of cputune ( libivirt format ) from NUMA node entities ( vNode pinto pNode ) Limitation: This structure of cputune will not get the best performance of vNode.
Best Regards, Jason Liao
----- Original Message -----
From: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao@hp.com> To: "Gilad Chaplik" <gchaplik@redhat.com> Cc: devel@ovirt.org, "Doron Fediuck" <dfediuck@redhat.com>, "Martin Sivák" <msivak@redhat.com>, "Juan Hernandez" <juan.hernandez@redhat.com>, "Malini Rao" <mrao@redhat.com>, "Chegu Vinod" <chegu_vinod@hp.com>, "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)" <shangchun.liang@hp.com>, "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi@hp.com> Sent: Friday, May 16, 2014 5:30:34 AM Subject: RE: Discussion VM CPU pinning and NUMA CPU pinning
Hi Gilad,
The restful API model of NUMA CPU and CPU-pinning is named NUMACPU ( Under NumaNode, VirutalNumaNode ) Which is contain some attributes; index (xs:int): Numa CPU index or vNuma CPU index. pin_set (xs:string): Virtual NUMA CPU pin to host NUMA CPU set. ( only enabled on VirtualNumaNode )
I think that CPU-pinning new modeling should be coupled with NUMA. also CPU is a Host sub-entity, so there shouldn't be NUMACPU.
BTW, Could you give us some update about UI layer solution of NUMA CPU-pinning configuration ?
[adding David's response as well, and answering to both questions]
Hi Gilad, Thanks for your reply. Did you submit the UI code. We need to know your UI model to consolidate your feedback. Meanwhile, we need to know the current cpu pining solution that include the UI code you are in charging. Then, we will see if we can specific to RESTful.
Best Regards, David Liang
As discussed, the CPU pinning modeling in GUI won't be handled in first phase (maybe as a 3.5 bug later on). The reason RESTful modeling is important now is obvious, GUI can wait, so there's shouldn't be any coupling between GUI and RESTful impl. Thanks, Gilad.
Best Regards, Jason Liao
-----Original Message----- From: Gilad Chaplik [mailto:gchaplik@redhat.com] Sent: 2014年5月15日 20:07 To: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC) Cc: devel@ovirt.org; Doron Fediuck; Martin Sivák; Juan Hernandez; Malini Rao; Vinod, Chegu; Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC); Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ) Subject: Re: Discussion VM CPU pinning and NUMA CPU pinning
Can you please be more specific on how to model RESTful API, with regards to CPU and CPU-pinning.
Thanks, Gilad.
----- Original Message -----
From: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao@hp.com> To: devel@ovirt.org Cc: "Doron Fediuck" <dfediuck@redhat.com>, "Gilad Chaplik" <gchaplik@redhat.com>, "Martin Sivák" <msivak@redhat.com>, "Juan Hernandez" <juan.hernandez@redhat.com>, "Malini Rao" <mrao@redhat.com>, "Chegu Vinod" <chegu_vinod@hp.com>, "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)" <shangchun.liang@hp.com>, "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi@hp.com> Sent: Thursday, May 15, 2014 2:50:23 PM Subject: Discussion VM CPU pinning and NUMA CPU pinning
Hi All,
Now we are working on the NUMA tune feature development for oVirt 3.5. This feature allow user to configure the vCPU pining according to host CPU/NUMA topology to get the best performance for created VM. But this will impact the current function of vCPU pining. Now, we are looking for a solution to consolidate the conflict. We want to start an open discussion about VM CPU pinning (the current design) and NUMA CPU pining (new feature we are working on) in developer list:
Background: Concept:
1. VM CPU pinning: the exist feature in current oVirt, which allow user to configure the VM vCPU pinning over ovirt, user can configure vCPU pining independently without NUMA tune.
2. NUMA CPU pinning: allow user to configure the vCPU pining according to host NUMA topology to get the best performance for created VM
3. vNode: Virtual NUMA node ( User configured )
4. pNode: host physical NUMA node ( Get capability from host ) Notice:
1. NUMA tuning feature and CPU pinning feature are individually in libvirt ( ovirt backend ).
2. User could configure VM CPU pining individually without NUMA tune setup.
3. When configuring NUMA tuning feature, user need to configure VM NUMA tuning ( vNode pinto pNode & tuning mode ) and VM CPU pinning ( NUMA included ) to get optimized VM performance, otherwise VM will have low performance.
We have two proposal now for this issue. Please give us some comments and your feedback, thanks.
Solution 1: GUI: Transform between the CPU pinning text and a structure which will be used in NUMA CPU pinning configure page. And then save the CPU pinning text to the current VM CPU pinning field of VM. Restful: Transform between the CPU pinning text and a structure which will be used in restful NUMA CPU pinning. And then save the CPU pinning text to the current VM CPU pinning field of VM. Broker: Remove temporary solution(See the current implementation as below) and follow previous cpupin configuration procedure.
Solution 2: GUI: If current VM CPU pinning is configured, when user open NUMA CPU pinning configure page, he will get a warning message. If he continues to configure NUMA CPU pinning and save the data, the current VM CPU pinning configuration will be cleared. NUMA CPU pinning configured data will be saved as new structure individually without changing current VM CPU pinning configuration. Restful: Configure NUMA CPU pinning and then save the data with the new NUMA CPU pinning structure. Entity and Database: Individually NUMA CPU pinning entities and data structure. Broker: NUMA CPU pinning configuration will be first considered to use. If it's not configured, it will use the current VM CPU pinning.
Solution 1 The CPU pining data is consistent but the code logic is very complex. Solution 2 have better adaptive and better data structure. This is the way we preferred.
We are appreciated that anybody could give us your comments or the better solution you have.
The below is the current implementation for your reference: VM CPU pinning feature GUI: User input vCPU pining configure data with formatted text. Restful: User configure CpuTune and VCpuPin model with mapper to CPU pinning text. Entity and Database: CPU pinning is String property. Broker: Generate structure of cputune ( libvirt format ) from CPU pining string property. NUMA tuning feature GUI: User can drag & drop virtual NUMA node to host NUMA node ( pin to or remove pin to ). Restful: Add/update/remove virtual NUMA node with property of pin to host NUMA node index. Design NUMACPU model under NUMA node for extend. Entity and Database: Individually NUMA node entities ( vNode extend pNode ) and store procedure. Broker: Generate structure of numatune, cpu/numa ( libvirt format ) from NUMA node entities. Temporary solution prevent Notice 3 Broker: Generate right structure of cputune ( libivirt format ) from NUMA node entities ( vNode pinto pNode ) Limitation: This structure of cputune will not get the best performance of vNode.
Best Regards, Jason Liao
----- Original Message -----
From: "Gilad Chaplik" <gchaplik@redhat.com> To: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao@hp.com>, "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)" <shangchun.liang@hp.com> Cc: devel@ovirt.org, "Doron Fediuck" <dfediuck@redhat.com>, "Martin Sivák" <msivak@redhat.com>, "Juan Hernandez" <juan.hernandez@redhat.com>, "Malini Rao" <mrao@redhat.com>, "Chegu Vinod" <chegu_vinod@hp.com>, "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi@hp.com> Sent: Sunday, May 18, 2014 5:21:32 PM Subject: Re: Discussion VM CPU pinning and NUMA CPU pinning
----- Original Message -----
From: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao@hp.com> To: "Gilad Chaplik" <gchaplik@redhat.com> Cc: devel@ovirt.org, "Doron Fediuck" <dfediuck@redhat.com>, "Martin Sivák" <msivak@redhat.com>, "Juan Hernandez" <juan.hernandez@redhat.com>, "Malini Rao" <mrao@redhat.com>, "Chegu Vinod" <chegu_vinod@hp.com>, "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)" <shangchun.liang@hp.com>, "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi@hp.com> Sent: Friday, May 16, 2014 5:30:34 AM Subject: RE: Discussion VM CPU pinning and NUMA CPU pinning
Hi Gilad,
The restful API model of NUMA CPU and CPU-pinning is named NUMACPU ( Under NumaNode, VirutalNumaNode ) Which is contain some attributes; index (xs:int): Numa CPU index or vNuma CPU index. pin_set (xs:string): Virtual NUMA CPU pin to host NUMA CPU set. ( only enabled on VirtualNumaNode )
I think that CPU-pinning new modeling should be coupled with NUMA.
/s/should/shouldn't
also CPU is a Host sub-entity, so there shouldn't be NUMACPU.
BTW, Could you give us some update about UI layer solution of NUMA CPU-pinning configuration ?
[adding David's response as well, and answering to both questions]
Hi Gilad, Thanks for your reply. Did you submit the UI code. We need to know your UI model to consolidate your feedback. Meanwhile, we need to know the current cpu pining solution that include the UI code you are in charging. Then, we will see if we can specific to RESTful.
Best Regards, David Liang
As discussed, the CPU pinning modeling in GUI won't be handled in first phase (maybe as a 3.5 bug later on). The reason RESTful modeling is important now is obvious, GUI can wait, so there's shouldn't be any coupling between GUI and RESTful impl.
Thanks, Gilad.
Best Regards, Jason Liao
-----Original Message----- From: Gilad Chaplik [mailto:gchaplik@redhat.com] Sent: 2014年5月15日 20:07 To: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC) Cc: devel@ovirt.org; Doron Fediuck; Martin Sivák; Juan Hernandez; Malini Rao; Vinod, Chegu; Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC); Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ) Subject: Re: Discussion VM CPU pinning and NUMA CPU pinning
Can you please be more specific on how to model RESTful API, with regards to CPU and CPU-pinning.
Thanks, Gilad.
----- Original Message -----
From: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao@hp.com> To: devel@ovirt.org Cc: "Doron Fediuck" <dfediuck@redhat.com>, "Gilad Chaplik" <gchaplik@redhat.com>, "Martin Sivák" <msivak@redhat.com>, "Juan Hernandez" <juan.hernandez@redhat.com>, "Malini Rao" <mrao@redhat.com>, "Chegu Vinod" <chegu_vinod@hp.com>, "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)" <shangchun.liang@hp.com>, "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi@hp.com> Sent: Thursday, May 15, 2014 2:50:23 PM Subject: Discussion VM CPU pinning and NUMA CPU pinning
Hi All,
Now we are working on the NUMA tune feature development for oVirt 3.5. This feature allow user to configure the vCPU pining according to host CPU/NUMA topology to get the best performance for created VM. But this will impact the current function of vCPU pining. Now, we are looking for a solution to consolidate the conflict. We want to start an open discussion about VM CPU pinning (the current design) and NUMA CPU pining (new feature we are working on) in developer list:
Background: Concept:
1. VM CPU pinning: the exist feature in current oVirt, which allow user to configure the VM vCPU pinning over ovirt, user can configure vCPU pining independently without NUMA tune.
2. NUMA CPU pinning: allow user to configure the vCPU pining according to host NUMA topology to get the best performance for created VM
3. vNode: Virtual NUMA node ( User configured )
4. pNode: host physical NUMA node ( Get capability from host ) Notice:
1. NUMA tuning feature and CPU pinning feature are individually in libvirt ( ovirt backend ).
2. User could configure VM CPU pining individually without NUMA tune setup.
3. When configuring NUMA tuning feature, user need to configure VM NUMA tuning ( vNode pinto pNode & tuning mode ) and VM CPU pinning ( NUMA included ) to get optimized VM performance, otherwise VM will have low performance.
We have two proposal now for this issue. Please give us some comments and your feedback, thanks.
Solution 1: GUI: Transform between the CPU pinning text and a structure which will be used in NUMA CPU pinning configure page. And then save the CPU pinning text to the current VM CPU pinning field of VM. Restful: Transform between the CPU pinning text and a structure which will be used in restful NUMA CPU pinning. And then save the CPU pinning text to the current VM CPU pinning field of VM. Broker: Remove temporary solution(See the current implementation as below) and follow previous cpupin configuration procedure.
Solution 2: GUI: If current VM CPU pinning is configured, when user open NUMA CPU pinning configure page, he will get a warning message. If he continues to configure NUMA CPU pinning and save the data, the current VM CPU pinning configuration will be cleared. NUMA CPU pinning configured data will be saved as new structure individually without changing current VM CPU pinning configuration. Restful: Configure NUMA CPU pinning and then save the data with the new NUMA CPU pinning structure. Entity and Database: Individually NUMA CPU pinning entities and data structure. Broker: NUMA CPU pinning configuration will be first considered to use. If it's not configured, it will use the current VM CPU pinning.
Solution 1 The CPU pining data is consistent but the code logic is very complex. Solution 2 have better adaptive and better data structure. This is the way we preferred.
We are appreciated that anybody could give us your comments or the better solution you have.
The below is the current implementation for your reference: VM CPU pinning feature GUI: User input vCPU pining configure data with formatted text. Restful: User configure CpuTune and VCpuPin model with mapper to CPU pinning text. Entity and Database: CPU pinning is String property. Broker: Generate structure of cputune ( libvirt format ) from CPU pining string property. NUMA tuning feature GUI: User can drag & drop virtual NUMA node to host NUMA node ( pin to or remove pin to ). Restful: Add/update/remove virtual NUMA node with property of pin to host NUMA node index. Design NUMACPU model under NUMA node for extend. Entity and Database: Individually NUMA node entities ( vNode extend pNode ) and store procedure. Broker: Generate structure of numatune, cpu/numa ( libvirt format ) from NUMA node entities. Temporary solution prevent Notice 3 Broker: Generate right structure of cputune ( libivirt format ) from NUMA node entities ( vNode pinto pNode ) Limitation: This structure of cputune will not get the best performance of vNode.
Best Regards, Jason Liao
Hi Gilad, Thanks for you mentioned. I want clarify some details with you. 1. The NumaCPU model is under the NumaNode and VirutalNumaNode model to show one NUMA node's inside cpu list. ( BE model property: VdsNumaNode.getCpuIds ) hosts/{host:id}/numanodes/{numa:id}/numacpus/numacpu [index="{numacpu.index}"] vms/{vm:id}/numanodes/{vnuma:id}/numacpus/numacpu [index="{numacpu.index}"] Notice: This is a completed solution for showing not setting. 2. VM CPU pinning in restful API is a completed solution using vm/{vm:id}/cpu/cputune/vcpupin model. 3. All the discussion is based on we want to do setting CPU pinning inside VirtualNumaNode. The whole solution should contain both UI model solution and restful API solution and backend solution. In restful API solution, we already design a extent point on model NUMACPU could support this. ( add an attribute cpu_set in NUMACPU model ) So, I am not sure about your options. User already could do setting CPU pinning for VM now, do we need to do setting CPU pinning inside VirtualiNumaNode in restful API ? Best Regards, Jason Liao
-----Original Message----- From: Gilad Chaplik [mailto:gchaplik@redhat.com] Sent: 2014年5月18日 22:22 To: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC) Cc: devel@ovirt.org; Doron Fediuck; Martin Sivák; Juan Hernandez; Malini Rao; Vinod, Chegu; Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ) Subject: Re: Discussion VM CPU pinning and NUMA CPU pinning
----- Original Message -----
From: "Gilad Chaplik" <gchaplik@redhat.com> To: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao@hp.com>, "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)" <shangchun.liang@hp.com> Cc: devel@ovirt.org, "Doron Fediuck" <dfediuck@redhat.com>, "Martin Sivák" <msivak@redhat.com>, "Juan Hernandez" <juan.hernandez@redhat.com>, "Malini Rao" <mrao@redhat.com>, "Chegu Vinod" <chegu_vinod@hp.com>, "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi@hp.com> Sent: Sunday, May 18, 2014 5:21:32 PM Subject: Re: Discussion VM CPU pinning and NUMA CPU pinning
----- Original Message -----
From: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao@hp.com> To: "Gilad Chaplik" <gchaplik@redhat.com> Cc: devel@ovirt.org, "Doron Fediuck" <dfediuck@redhat.com>, "Martin Sivák" <msivak@redhat.com>, "Juan Hernandez" <juan.hernandez@redhat.com>, "Malini Rao" <mrao@redhat.com>, "Chegu Vinod" <chegu_vinod@hp.com>, "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)" <shangchun.liang@hp.com>, "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi@hp.com> Sent: Friday, May 16, 2014 5:30:34 AM Subject: RE: Discussion VM CPU pinning and NUMA CPU pinning
Hi Gilad,
The restful API model of NUMA CPU and CPU-pinning is named NUMACPU ( Under NumaNode, VirutalNumaNode ) Which is contain some attributes; index (xs:int): Numa CPU index or vNuma CPU index. pin_set (xs:string): Virtual NUMA CPU pin to host NUMA CPU set. ( only enabled on VirtualNumaNode )
I think that CPU-pinning new modeling should be coupled with NUMA.
/s/should/shouldn't
also CPU is a Host sub-entity, so there shouldn't be NUMACPU.
BTW, Could you give us some update about UI layer solution of NUMA CPU-pinning configuration ?
[adding David's response as well, and answering to both questions]
Hi Gilad, Thanks for your reply. Did you submit the UI code. We need to know your UI model to consolidate your feedback. Meanwhile, we need to know the current cpu pining solution that include the UI code you are in charging. Then, we will see if we can specific to RESTful.
Best Regards, David Liang
As discussed, the CPU pinning modeling in GUI won't be handled in first phase (maybe as a 3.5 bug later on). The reason RESTful modeling is important now is obvious, GUI can wait, so there's shouldn't be any coupling between GUI and RESTful impl.
Thanks, Gilad.
Best Regards, Jason Liao
-----Original Message----- From: Gilad Chaplik [mailto:gchaplik@redhat.com] Sent: 2014年5月15日 20:07 To: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC) Cc: devel@ovirt.org; Doron Fediuck; Martin Sivák; Juan Hernandez; Malini Rao; Vinod, Chegu; Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC); Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ) Subject: Re: Discussion VM CPU pinning and NUMA CPU pinning
Can you please be more specific on how to model RESTful API, with regards to CPU and CPU-pinning.
Thanks, Gilad.
----- Original Message -----
From: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao@hp.com> To: devel@ovirt.org Cc: "Doron Fediuck" <dfediuck@redhat.com>, "Gilad Chaplik" <gchaplik@redhat.com>, "Martin Sivák" <msivak@redhat.com>, "Juan Hernandez" <juan.hernandez@redhat.com>, "Malini Rao" <mrao@redhat.com>, "Chegu Vinod" <chegu_vinod@hp.com>, "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)" <shangchun.liang@hp.com>, "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi@hp.com> Sent: Thursday, May 15, 2014 2:50:23 PM Subject: Discussion VM CPU pinning and NUMA CPU pinning
Hi All,
Now we are working on the NUMA tune feature development for oVirt 3.5. This feature allow user to configure the vCPU pining according to host CPU/NUMA topology to get the best performance for created VM. But this will impact the current function of vCPU pining. Now, we are looking for a solution to consolidate the conflict. We want to start an open discussion about VM CPU pinning (the current design) and NUMA CPU pining (new feature we are working on) in developer list:
Background: Concept:
1. VM CPU pinning: the exist feature in current oVirt, which allow user to configure the VM vCPU pinning over ovirt, user can configure vCPU pining independently without NUMA tune.
2. NUMA CPU pinning: allow user to configure the vCPU pining according to host NUMA topology to get the best performance for created VM
3. vNode: Virtual NUMA node ( User configured )
4. pNode: host physical NUMA node ( Get capability from host ) Notice:
1. NUMA tuning feature and CPU pinning feature are individually in libvirt ( ovirt backend ).
2. User could configure VM CPU pining individually without NUMA tune setup.
3. When configuring NUMA tuning feature, user need to configure VM NUMA tuning ( vNode pinto pNode & tuning mode ) and VM CPU pinning ( NUMA included ) to get optimized VM performance, otherwise VM will have low performance.
We have two proposal now for this issue. Please give us some comments and your feedback, thanks.
Solution 1: GUI: Transform between the CPU pinning text and a structure which will be used in NUMA CPU pinning configure page. And then save the CPU pinning text to the current VM CPU pinning field of VM. Restful: Transform between the CPU pinning text and a structure which will be used in restful NUMA CPU pinning. And then save the CPU pinning text to the current VM CPU pinning field of VM. Broker: Remove temporary solution(See the current implementation as below) and follow previous cpupin configuration procedure.
Solution 2: GUI: If current VM CPU pinning is configured, when user open NUMA CPU pinning configure page, he will get a warning message. If he continues to configure NUMA CPU pinning and save the data, the current VM CPU pinning configuration will be cleared. NUMA CPU pinning configured data will be saved as new structure individually without changing current VM CPU pinning configuration. Restful: Configure NUMA CPU pinning and then save the data with the new NUMA CPU pinning structure. Entity and Database: Individually NUMA CPU pinning entities and data structure. Broker: NUMA CPU pinning configuration will be first considered to use. If it's not configured, it will use the current VM CPU pinning.
Solution 1 The CPU pining data is consistent but the code logic is very complex. Solution 2 have better adaptive and better data structure. This is the way we preferred.
We are appreciated that anybody could give us your comments or the better solution you have.
The below is the current implementation for your reference: VM CPU pinning feature GUI: User input vCPU pining configure data with formatted text. Restful: User configure CpuTune and VCpuPin model with mapper to CPU pinning text. Entity and Database: CPU pinning is String property. Broker: Generate structure of cputune ( libvirt format ) from CPU pining string property. NUMA tuning feature GUI: User can drag & drop virtual NUMA node to host NUMA node ( pin to or remove pin to ). Restful: Add/update/remove virtual NUMA node with property of pin to host NUMA node index. Design NUMACPU model under NUMA node for extend. Entity and Database: Individually NUMA node entities ( vNode extend pNode ) and store procedure. Broker: Generate structure of numatune, cpu/numa ( libvirt format ) from NUMA node entities. Temporary solution prevent Notice 3 Broker: Generate right structure of cputune ( libivirt format ) from NUMA node entities ( vNode pinto pNode ) Limitation: This structure of cputune will not get the best performance of vNode.
Best Regards, Jason Liao
Hi All, After discussion with some community members, we are supposed to make some conclusion of this topic. Change API model object on api.xsd 1. remove NumaCPU and NumaCPUs from NumaNode and VirtualNumaNode. 2. add Core and Cores under the CPU to show the CPU topology details. 3. add the CPU under the NumaNode and VirtualNumaNode to show the Numa inside CPU topology details. The CPU model will defined like this: <xs:complexType name="CPU"> <xs:sequence> ... <xs:element name="cores" type="Cores" minOccurs="0"/> ... </xs:complexType> <xs:complexType name="Cores"> <xs:sequence> <xs:element ref="core" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> <xs:complexType name="Core"> <xs:attribute name="index" type="xs:int" use="required"/> <xs:attribute name="socket" type="xs:int" use="optional"/> </xs:complexType> Change related backend implementation on NumaMapper and YAML defined files. We are appreciated that anyone could give us some suggestion and feedback before 2014/5/30. Best Regards, Jason Liao
-----Original Message----- From: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC) Sent: 2014年5月19日 10:34 To: 'Gilad Chaplik'; Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC) Cc: devel@ovirt.org; Doron Fediuck; Martin Sivák; Juan Hernandez; Malini Rao; Vinod, Chegu; Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ) Subject: RE: Discussion VM CPU pinning and NUMA CPU pinning
Hi Gilad,
Thanks for you mentioned. I want clarify some details with you.
1. The NumaCPU model is under the NumaNode and VirutalNumaNode model to show one NUMA node's inside cpu list. ( BE model property: VdsNumaNode.getCpuIds ) hosts/{host:id}/numanodes/{numa:id}/numacpus/numacpu [index="{numacpu.index}"] vms/{vm:id}/numanodes/{vnuma:id}/numacpus/numacpu [index="{numacpu.index}"] Notice: This is a completed solution for showing not setting.
2. VM CPU pinning in restful API is a completed solution using vm/{vm:id}/cpu/cputune/vcpupin model.
3. All the discussion is based on we want to do setting CPU pinning inside VirtualNumaNode. The whole solution should contain both UI model solution and restful API solution and backend solution. In restful API solution, we already design a extent point on model NUMACPU could support this. ( add an attribute cpu_set in NUMACPU model )
So, I am not sure about your options. User already could do setting CPU pinning for VM now, do we need to do setting CPU pinning inside VirtualiNumaNode in restful API ?
Best Regards, Jason Liao
-----Original Message----- From: Gilad Chaplik [mailto:gchaplik@redhat.com] Sent: 2014年5月18日 22:22 To: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC) Cc: devel@ovirt.org; Doron Fediuck; Martin Sivák; Juan Hernandez; Malini Rao; Vinod, Chegu; Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ) Subject: Re: Discussion VM CPU pinning and NUMA CPU pinning
----- Original Message -----
From: "Gilad Chaplik" <gchaplik@redhat.com> To: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao@hp.com>, "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)" <shangchun.liang@hp.com> Cc: devel@ovirt.org, "Doron Fediuck" <dfediuck@redhat.com>, "Martin Sivák" <msivak@redhat.com>, "Juan Hernandez" <juan.hernandez@redhat.com>, "Malini Rao" <mrao@redhat.com>, "Chegu Vinod" <chegu_vinod@hp.com>, "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi@hp.com> Sent: Sunday, May 18, 2014 5:21:32 PM Subject: Re: Discussion VM CPU pinning and NUMA CPU pinning
----- Original Message -----
From: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao@hp.com> To: "Gilad Chaplik" <gchaplik@redhat.com> Cc: devel@ovirt.org, "Doron Fediuck" <dfediuck@redhat.com>, "Martin Sivák" <msivak@redhat.com>, "Juan Hernandez" <juan.hernandez@redhat.com>, "Malini Rao" <mrao@redhat.com>, "Chegu Vinod" <chegu_vinod@hp.com>, "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)" <shangchun.liang@hp.com>, "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi@hp.com> Sent: Friday, May 16, 2014 5:30:34 AM Subject: RE: Discussion VM CPU pinning and NUMA CPU pinning
Hi Gilad,
The restful API model of NUMA CPU and CPU-pinning is named NUMACPU ( Under NumaNode, VirutalNumaNode ) Which is contain some attributes; index (xs:int): Numa CPU index or vNuma CPU index. pin_set (xs:string): Virtual NUMA CPU pin to host NUMA CPU set. ( only enabled on VirtualNumaNode )
I think that CPU-pinning new modeling should be coupled with NUMA.
/s/should/shouldn't
also CPU is a Host sub-entity, so there shouldn't be NUMACPU.
BTW, Could you give us some update about UI layer solution of NUMA CPU-pinning configuration ?
[adding David's response as well, and answering to both questions]
Hi Gilad, Thanks for your reply. Did you submit the UI code. We need to know your UI model to consolidate your feedback. Meanwhile, we need to know the current cpu pining solution that include the UI code you are in charging. Then, we will see if we can specific to RESTful.
Best Regards, David Liang
As discussed, the CPU pinning modeling in GUI won't be handled in first phase (maybe as a 3.5 bug later on). The reason RESTful modeling is important now is obvious, GUI can wait, so there's shouldn't be any coupling between GUI and RESTful impl.
Thanks, Gilad.
Best Regards, Jason Liao
-----Original Message----- From: Gilad Chaplik [mailto:gchaplik@redhat.com] Sent: 2014年5月15日 20:07 To: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC) Cc: devel@ovirt.org; Doron Fediuck; Martin Sivák; Juan Hernandez; Malini Rao; Vinod, Chegu; Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC); Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ) Subject: Re: Discussion VM CPU pinning and NUMA CPU pinning
Can you please be more specific on how to model RESTful API, with regards to CPU and CPU-pinning.
Thanks, Gilad.
----- Original Message -----
From: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao@hp.com> To: devel@ovirt.org Cc: "Doron Fediuck" <dfediuck@redhat.com>, "Gilad Chaplik" <gchaplik@redhat.com>, "Martin Sivák" <msivak@redhat.com>, "Juan Hernandez" <juan.hernandez@redhat.com>, "Malini Rao" <mrao@redhat.com>, "Chegu Vinod" <chegu_vinod@hp.com>, "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)" <shangchun.liang@hp.com>, "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi@hp.com> Sent: Thursday, May 15, 2014 2:50:23 PM Subject: Discussion VM CPU pinning and NUMA CPU pinning
Hi All,
Now we are working on the NUMA tune feature development for oVirt 3.5. This feature allow user to configure the vCPU pining according to host CPU/NUMA topology to get the best performance for created VM. But this will impact the current function of vCPU pining. Now, we are looking for a solution to consolidate the conflict. We want to start an open discussion about VM CPU pinning (the current design) and NUMA CPU pining (new feature we are working on) in developer list:
Background: Concept:
1. VM CPU pinning: the exist feature in current oVirt, which allow user to configure the VM vCPU pinning over ovirt, user can configure vCPU pining independently without NUMA tune.
2. NUMA CPU pinning: allow user to configure the vCPU pining according to host NUMA topology to get the best performance for created VM
3. vNode: Virtual NUMA node ( User configured )
4. pNode: host physical NUMA node ( Get capability from host ) Notice:
1. NUMA tuning feature and CPU pinning feature are individually in libvirt ( ovirt backend ).
2. User could configure VM CPU pining individually without NUMA tune setup.
3. When configuring NUMA tuning feature, user need to configure VM NUMA tuning ( vNode pinto pNode & tuning mode ) and VM CPU pinning ( NUMA included ) to get optimized VM performance, otherwise VM will have low performance.
We have two proposal now for this issue. Please give us some comments and your feedback, thanks.
Solution 1: GUI: Transform between the CPU pinning text and a structure which will be used in NUMA CPU pinning configure page. And then save the CPU pinning text to the current VM CPU pinning field of VM. Restful: Transform between the CPU pinning text and a structure which will be used in restful NUMA CPU pinning. And then save the CPU pinning text to the current VM CPU pinning field of VM. Broker: Remove temporary solution(See the current implementation as below) and follow previous cpupin configuration procedure.
Solution 2: GUI: If current VM CPU pinning is configured, when user open NUMA CPU pinning configure page, he will get a warning message. If he continues to configure NUMA CPU pinning and save the data, the current VM CPU pinning configuration will be cleared. NUMA CPU pinning configured data will be saved as new structure individually without changing current VM CPU pinning configuration. Restful: Configure NUMA CPU pinning and then save the data with the new NUMA CPU pinning structure. Entity and Database: Individually NUMA CPU pinning entities and data structure. Broker: NUMA CPU pinning configuration will be first considered to use. If it's not configured, it will use the current VM CPU pinning.
Solution 1 The CPU pining data is consistent but the code logic is very complex. Solution 2 have better adaptive and better data structure. This is the way we preferred.
We are appreciated that anybody could give us your comments or the better solution you have.
The below is the current implementation for your reference: VM CPU pinning feature GUI: User input vCPU pining configure data with formatted text. Restful: User configure CpuTune and VCpuPin model with mapper to CPU pinning text. Entity and Database: CPU pinning is String property. Broker: Generate structure of cputune ( libvirt format ) from CPU pining string property. NUMA tuning feature GUI: User can drag & drop virtual NUMA node to host NUMA node ( pin to or remove pin to ). Restful: Add/update/remove virtual NUMA node with property of pin to host NUMA node index. Design NUMACPU model under NUMA node for extend. Entity and Database: Individually NUMA node entities ( vNode extend pNode ) and store procedure. Broker: Generate structure of numatune, cpu/numa ( libvirt format ) from NUMA node entities. Temporary solution prevent Notice 3 Broker: Generate right structure of cputune ( libivirt format ) from NUMA node entities ( vNode pinto pNode ) Limitation: This structure of cputune will not get the best performance of vNode.
Best Regards, Jason Liao
----- Original Message -----
From: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao@hp.com> To: devel@ovirt.org Cc: "Doron Fediuck" <dfediuck@redhat.com>, "Martin Sivák" <msivak@redhat.com>, "Juan Hernandez" <juan.hernandez@redhat.com>, "Malini Rao" <mrao@redhat.com>, "Chegu Vinod" <chegu_vinod@hp.com>, "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi@hp.com>, "Gilad Chaplik" <gchaplik@redhat.com>, "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)" <shangchun.liang@hp.com> Sent: Monday, May 26, 2014 6:11:35 AM Subject: RE: Discussion VM CPU pinning and NUMA CPU pinning
Hi All,
After discussion with some community members, we are supposed to make some conclusion of this topic.
Change API model object on api.xsd 1. remove NumaCPU and NumaCPUs from NumaNode and VirtualNumaNode. 2. add Core and Cores under the CPU to show the CPU topology details. 3. add the CPU under the NumaNode and VirtualNumaNode to show the Numa inside CPU topology details.
The CPU model will defined like this: <xs:complexType name="CPU"> <xs:sequence> ... <xs:element name="cores" type="Cores" minOccurs="0"/> ... </xs:complexType>
<xs:complexType name="Cores"> <xs:sequence> <xs:element ref="core" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType>
<xs:complexType name="Core"> <xs:attribute name="index" type="xs:int" use="required"/> <xs:attribute name="socket" type="xs:int" use="optional"/>
Not a cpu topology expert but isn't core contained within a socket? and the other way around? but I guess this informative attribute is good enough. I'm +1.
</xs:complexType>
Change related backend implementation on NumaMapper and YAML defined files.
We are appreciated that anyone could give us some suggestion and feedback before 2014/5/30.
Best Regards, Jason Liao
-----Original Message----- From: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC) Sent: 2014年5月19日 10:34 To: 'Gilad Chaplik'; Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC) Cc: devel@ovirt.org; Doron Fediuck; Martin Sivák; Juan Hernandez; Malini Rao; Vinod, Chegu; Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ) Subject: RE: Discussion VM CPU pinning and NUMA CPU pinning
Hi Gilad,
Thanks for you mentioned. I want clarify some details with you.
1. The NumaCPU model is under the NumaNode and VirutalNumaNode model to show one NUMA node's inside cpu list. ( BE model property: VdsNumaNode.getCpuIds ) hosts/{host:id}/numanodes/{numa:id}/numacpus/numacpu [index="{numacpu.index}"] vms/{vm:id}/numanodes/{vnuma:id}/numacpus/numacpu [index="{numacpu.index}"] Notice: This is a completed solution for showing not setting.
2. VM CPU pinning in restful API is a completed solution using vm/{vm:id}/cpu/cputune/vcpupin model.
3. All the discussion is based on we want to do setting CPU pinning inside VirtualNumaNode. The whole solution should contain both UI model solution and restful API solution and backend solution. In restful API solution, we already design a extent point on model NUMACPU could support this. ( add an attribute cpu_set in NUMACPU model )
So, I am not sure about your options. User already could do setting CPU pinning for VM now, do we need to do setting CPU pinning inside VirtualiNumaNode in restful API ?
Best Regards, Jason Liao
-----Original Message----- From: Gilad Chaplik [mailto:gchaplik@redhat.com] Sent: 2014年5月18日 22:22 To: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC); Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC) Cc: devel@ovirt.org; Doron Fediuck; Martin Sivák; Juan Hernandez; Malini Rao; Vinod, Chegu; Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ) Subject: Re: Discussion VM CPU pinning and NUMA CPU pinning
----- Original Message -----
From: "Gilad Chaplik" <gchaplik@redhat.com> To: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao@hp.com>, "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)" <shangchun.liang@hp.com> Cc: devel@ovirt.org, "Doron Fediuck" <dfediuck@redhat.com>, "Martin Sivák" <msivak@redhat.com>, "Juan Hernandez" <juan.hernandez@redhat.com>, "Malini Rao" <mrao@redhat.com>, "Chegu Vinod" <chegu_vinod@hp.com>, "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi@hp.com> Sent: Sunday, May 18, 2014 5:21:32 PM Subject: Re: Discussion VM CPU pinning and NUMA CPU pinning
----- Original Message -----
From: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao@hp.com> To: "Gilad Chaplik" <gchaplik@redhat.com> Cc: devel@ovirt.org, "Doron Fediuck" <dfediuck@redhat.com>, "Martin Sivák" <msivak@redhat.com>, "Juan Hernandez" <juan.hernandez@redhat.com>, "Malini Rao" <mrao@redhat.com>, "Chegu Vinod" <chegu_vinod@hp.com>, "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)" <shangchun.liang@hp.com>, "Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ)" <xiao-lei.shi@hp.com> Sent: Friday, May 16, 2014 5:30:34 AM Subject: RE: Discussion VM CPU pinning and NUMA CPU pinning
Hi Gilad,
The restful API model of NUMA CPU and CPU-pinning is named NUMACPU ( Under NumaNode, VirutalNumaNode ) Which is contain some attributes; index (xs:int): Numa CPU index or vNuma CPU index. pin_set (xs:string): Virtual NUMA CPU pin to host NUMA CPU set. ( only enabled on VirtualNumaNode )
I think that CPU-pinning new modeling should be coupled with NUMA.
/s/should/shouldn't
also CPU is a Host sub-entity, so there shouldn't be NUMACPU.
BTW, Could you give us some update about UI layer solution of NUMA CPU-pinning configuration ?
[adding David's response as well, and answering to both questions]
Hi Gilad, Thanks for your reply. Did you submit the UI code. We need to know your UI model to consolidate your feedback. Meanwhile, we need to know the current cpu pining solution that include the UI code you are in charging. Then, we will see if we can specific to RESTful.
Best Regards, David Liang
As discussed, the CPU pinning modeling in GUI won't be handled in first phase (maybe as a 3.5 bug later on). The reason RESTful modeling is important now is obvious, GUI can wait, so there's shouldn't be any coupling between GUI and RESTful impl.
Thanks, Gilad.
Best Regards, Jason Liao
-----Original Message----- From: Gilad Chaplik [mailto:gchaplik@redhat.com] Sent: 2014年5月15日 20:07 To: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC) Cc: devel@ovirt.org; Doron Fediuck; Martin Sivák; Juan Hernandez; Malini Rao; Vinod, Chegu; Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC); Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ) Subject: Re: Discussion VM CPU pinning and NUMA CPU pinning
Can you please be more specific on how to model RESTful API, with regards to CPU and CPU-pinning.
Thanks, Gilad.
----- Original Message ----- > From: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" > <chuan.liao@hp.com> > To: devel@ovirt.org > Cc: "Doron Fediuck" <dfediuck@redhat.com>, "Gilad Chaplik" <gchaplik@redhat.com>, "Martin Sivák" <msivak@redhat.com>, > "Juan Hernandez" <juan.hernandez@redhat.com>, "Malini Rao" <mrao@redhat.com>, "Chegu Vinod" <chegu_vinod@hp.com>, > "Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC)" <shangchun.liang@hp.com>, "Xiao-Lei Shi (Bruce, HP > Servers-PSC-CQ)" <xiao-lei.shi@hp.com> > Sent: Thursday, May 15, 2014 2:50:23 PM > Subject: Discussion VM CPU pinning and NUMA CPU pinning > > Hi All, > > Now we are working on the NUMA tune feature development for oVirt > 3.5. > This > feature allow user to configure the vCPU pining according to > host CPU/NUMA topology to get the best performance for created > VM. But this will impact the current function of vCPU pining. > Now, we are looking for a solution to consolidate the conflict. > We want to start an open discussion about VM CPU pinning (the > current design) and NUMA CPU pining (new feature we are > working > on) in developer list: > > Background: > Concept: > > 1. VM CPU pinning: the exist feature in current oVirt, which > allow > user > to configure the VM vCPU pinning over ovirt, user can > configure vCPU pining independently without NUMA tune. > > 2. NUMA CPU pinning: allow user to configure the vCPU pining > according > to host NUMA topology to get the best performance for created > VM > > 3. vNode: Virtual NUMA node ( User configured ) > > 4. pNode: host physical NUMA node ( Get capability from host > ) > Notice: > > 1. NUMA tuning feature and CPU pinning feature are > individually in > libvirt ( ovirt backend ). > > 2. User could configure VM CPU pining individually without > NUMA > tune > setup. > > 3. When configuring NUMA tuning feature, user need to > configure VM > NUMA > tuning ( vNode pinto pNode & tuning mode ) and VM CPU pinning > ( NUMA included ) to get optimized VM performance, otherwise > VM will have low performance. > > We have two proposal now for this issue. Please give us some > comments and your feedback, thanks. > > Solution 1: > GUI: > Transform between the CPU pinning text and a structure which > will be used in NUMA CPU pinning configure page. > And then save the CPU pinning text to the current VM CPU > pinning > field of > VM. > Restful: > Transform between the CPU pinning text and a structure which > will be used in restful NUMA CPU pinning. > And then save the CPU pinning text to the current VM CPU > pinning field of VM. > Broker: > Remove temporary solution(See the current implementation as > below) and follow previous cpupin configuration procedure. > > Solution 2: > GUI: > If current VM CPU pinning is configured, when user open NUMA > CPU pinning configure page, he will get a warning message. If > he continues to configure NUMA CPU pinning and save the data, > the current VM CPU pinning configuration will be cleared. > NUMA CPU pinning configured data will be saved as new > structure individually without changing current VM CPU pinning > configuration. > Restful: > Configure NUMA CPU pinning and then save the data with the new > NUMA CPU pinning structure. > Entity and Database: > Individually NUMA CPU pinning entities and data structure. > Broker: > NUMA CPU pinning configuration will be first considered > to > use. > If > it's not configured, it will use the current VM CPU > pinning. > > Solution 1 The CPU pining data is consistent but the code > logic is very complex. > Solution 2 have better adaptive and better data structure. > This is the way we preferred. > > We are appreciated that anybody could give us your comments or > the better solution you have. > > > > The below is the current implementation for your reference: > VM CPU pinning feature > GUI: > User input vCPU pining configure data with formatted text. > Restful: > User configure CpuTune and VCpuPin model with mapper to CPU > pinning text. > Entity and Database: > CPU pinning is String property. > Broker: > Generate structure of cputune ( libvirt format ) from CPU > pining string property. > NUMA tuning feature > GUI: > User can drag & drop virtual NUMA node to host NUMA node ( pin > to or remove pin to ). > Restful: > Add/update/remove virtual NUMA node with property of pin to > host NUMA node index. > Design NUMACPU model under NUMA node for extend. > Entity and Database: > Individually NUMA node entities ( vNode extend pNode ) and > store procedure. > Broker: > Generate structure of numatune, cpu/numa ( libvirt format ) > from NUMA node entities. > Temporary solution prevent Notice 3 > Broker: > Generate right structure of cputune ( libivirt format ) from > NUMA node entities ( vNode pinto pNode ) > Limitation: > This structure of cputune will not get the best performance of > vNode. > > Best Regards, > Jason Liao > >
well I'm no expert in reading xml like model declarations so please correct me where I'm wrong: any cpu contains at least 1 core, bound to 1 socket (1 cpu == 1 socket) a core does not contain any element socket. Am 26.05.2014 05:11, schrieb Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC):
<xs:complexType name="CPU"> <xs:sequence> ... <xs:element name="cores" type="Cores" minOccurs="0"/> ... </xs:complexType>
<xs:complexType name="Cores"> <xs:sequence> <xs:element ref="core" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType>
<xs:complexType name="Core"> <xs:attribute name="index" type="xs:int" use="required"/> <xs:attribute name="socket" type="xs:int" use="optional"/> </xs:complexType>
-- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
Yes, you are right. And this design is almost like the libvirt capabilities format <cpu id='0' socket_id='0' core_id='0' siblings='0'/> with attribute socket. Best Regards, Jason Liao
-----Original Message----- From: devel-bounces@ovirt.org [mailto:devel-bounces@ovirt.org] On Behalf Of Sven Kieske Sent: 2014年5月26日 23:51 To: devel@ovirt.org Subject: Re: [ovirt-devel] Discussion VM CPU pinning and NUMA CPU pinning
well I'm no expert in reading xml like model declarations so please correct me where I'm wrong:
any cpu contains at least 1 core, bound to 1 socket (1 cpu == 1 socket) a core does not contain any element socket.
Am 26.05.2014 05:11, schrieb Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC):
<xs:complexType name="CPU"> <xs:sequence> ... <xs:element name="cores" type="Cores" minOccurs="0"/> ... </xs:complexType>
<xs:complexType name="Cores"> <xs:sequence> <xs:element ref="core" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType>
<xs:complexType name="Core"> <xs:attribute name="index" type="xs:int" use="required"/> <xs:attribute name="socket" type="xs:int" use="optional"/> </xs:complexType>
-- Mit freundlichen Grüßen / Regards
Sven Kieske
Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Hi Jason, I guess that the time you've waited for feedback is sufficient. please upload a patch as described (I hope I will get it merged tomorrow). Thanks, Gilad. ----- Original Message -----
From: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao@hp.com> To: "Sven Kieske" <S.Kieske@mittwald.de>, devel@ovirt.org Sent: Tuesday, May 27, 2014 5:08:55 AM Subject: Re: [ovirt-devel] Discussion VM CPU pinning and NUMA CPU pinning
Yes, you are right.
And this design is almost like the libvirt capabilities format
<cpu id='0' socket_id='0' core_id='0' siblings='0'/> with attribute socket.
Best Regards, Jason Liao
-----Original Message----- From: devel-bounces@ovirt.org [mailto:devel-bounces@ovirt.org] On Behalf Of Sven Kieske Sent: 2014年5月26日 23:51 To: devel@ovirt.org Subject: Re: [ovirt-devel] Discussion VM CPU pinning and NUMA CPU pinning
well I'm no expert in reading xml like model declarations so please correct me where I'm wrong:
any cpu contains at least 1 core, bound to 1 socket (1 cpu == 1 socket) a core does not contain any element socket.
Am 26.05.2014 05:11, schrieb Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC):
<xs:complexType name="CPU"> <xs:sequence> ... <xs:element name="cores" type="Cores" minOccurs="0"/> ... </xs:complexType>
<xs:complexType name="Cores"> <xs:sequence> <xs:element ref="core" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType>
<xs:complexType name="Core"> <xs:attribute name="index" type="xs:int" use="required"/> <xs:attribute name="socket" type="xs:int" use="optional"/> </xs:complexType>
-- Mit freundlichen Grüßen / Regards
Sven Kieske
Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
The patch is already upload yesterday, and verified with latest rebase. http://gerrit.ovirt.org/#/c/26943/ Best Regards, Jason Liao
-----Original Message----- From: Gilad Chaplik [mailto:gchaplik@redhat.com] Sent: 2014年5月27日 21:52 To: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC) Cc: Sven Kieske; devel@ovirt.org Subject: Re: [ovirt-devel] Discussion VM CPU pinning and NUMA CPU pinning
Hi Jason,
I guess that the time you've waited for feedback is sufficient.
please upload a patch as described (I hope I will get it merged tomorrow).
Thanks, Gilad.
----- Original Message -----
From: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao@hp.com> To: "Sven Kieske" <S.Kieske@mittwald.de>, devel@ovirt.org Sent: Tuesday, May 27, 2014 5:08:55 AM Subject: Re: [ovirt-devel] Discussion VM CPU pinning and NUMA CPU pinning
Yes, you are right.
And this design is almost like the libvirt capabilities format
<cpu id='0' socket_id='0' core_id='0' siblings='0'/> with attribute socket.
Best Regards, Jason Liao
-----Original Message----- From: devel-bounces@ovirt.org [mailto:devel-bounces@ovirt.org] On Behalf Of Sven Kieske Sent: 2014年5月26日 23:51 To: devel@ovirt.org Subject: Re: [ovirt-devel] Discussion VM CPU pinning and NUMA CPU pinning
well I'm no expert in reading xml like model declarations so please correct me where I'm wrong:
any cpu contains at least 1 core, bound to 1 socket (1 cpu == 1 socket) a core does not contain any element socket.
Am 26.05.2014 05:11, schrieb Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC):
<xs:complexType name="CPU"> <xs:sequence> ... <xs:element name="cores" type="Cores" minOccurs="0"/> ... </xs:complexType>
<xs:complexType name="Cores"> <xs:sequence> <xs:element ref="core" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType>
<xs:complexType name="Core"> <xs:attribute name="index" type="xs:int" use="required"/> <xs:attribute name="socket" type="xs:int" use="optional"/> </xs:complexType>
-- Mit freundlichen Grüßen / Regards
Sven Kieske
Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Great! sorry, I wasn't aware of it. fyi, this patch depends on oVirt scheduling patch for NUMA (it's a must since we now expose an API to the user). I will upload it today, try to get them reviewed, and merge both. Thanks, Gilad. ----- Original Message -----
From: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao@hp.com> To: "Gilad Chaplik" <gchaplik@redhat.com> Cc: "Sven Kieske" <S.Kieske@mittwald.de>, devel@ovirt.org Sent: Wednesday, May 28, 2014 5:14:39 AM Subject: RE: [ovirt-devel] Discussion VM CPU pinning and NUMA CPU pinning
The patch is already upload yesterday, and verified with latest rebase. http://gerrit.ovirt.org/#/c/26943/
Best Regards, Jason Liao
-----Original Message----- From: Gilad Chaplik [mailto:gchaplik@redhat.com] Sent: 2014年5月27日 21:52 To: Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC) Cc: Sven Kieske; devel@ovirt.org Subject: Re: [ovirt-devel] Discussion VM CPU pinning and NUMA CPU pinning
Hi Jason,
I guess that the time you've waited for feedback is sufficient.
please upload a patch as described (I hope I will get it merged tomorrow).
Thanks, Gilad.
----- Original Message -----
From: "Chuan Liao (Jason Liao, HPservers-Core-OE-PSC)" <chuan.liao@hp.com> To: "Sven Kieske" <S.Kieske@mittwald.de>, devel@ovirt.org Sent: Tuesday, May 27, 2014 5:08:55 AM Subject: Re: [ovirt-devel] Discussion VM CPU pinning and NUMA CPU pinning
Yes, you are right.
And this design is almost like the libvirt capabilities format
<cpu id='0' socket_id='0' core_id='0' siblings='0'/> with attribute socket.
Best Regards, Jason Liao
-----Original Message----- From: devel-bounces@ovirt.org [mailto:devel-bounces@ovirt.org] On Behalf Of Sven Kieske Sent: 2014年5月26日 23:51 To: devel@ovirt.org Subject: Re: [ovirt-devel] Discussion VM CPU pinning and NUMA CPU pinning
well I'm no expert in reading xml like model declarations so please correct me where I'm wrong:
any cpu contains at least 1 core, bound to 1 socket (1 cpu == 1 socket) a core does not contain any element socket.
Am 26.05.2014 05:11, schrieb Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC):
<xs:complexType name="CPU"> <xs:sequence> ... <xs:element name="cores" type="Cores" minOccurs="0"/> ... </xs:complexType>
<xs:complexType name="Cores"> <xs:sequence> <xs:element ref="core" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType>
<xs:complexType name="Core"> <xs:attribute name="index" type="xs:int" use="required"/> <xs:attribute name="socket" type="xs:int" use="optional"/> </xs:complexType>
-- Mit freundlichen Grüßen / Regards
Sven Kieske
Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
participants (4)
-
Gilad Chaplik -
Liang, Shang-Chun (David Liang, HPservers-Core-OE-PSC) -
Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC) -
Sven Kieske