Hey everyone, I hope you guys can help me explaining a pretty strange result that came up when benchmarking a native Red Hat installation against a Xen DomU (installed in a file container). I used lmbench3 on a dualcore AMD-machine. To make the results comparable, I "unplugged" all CPU cores but one in the native installation (setting the "online"-entry to 0). The DomU had only one vCPU assigned. The installed packages on both machines were identical as well. After doing the initial configuration of lmbench3 I ran a script doing 10 times a "make rerun". All results seem to be OK somehow. But I cannot explain why Xen is faster than the native installation when creating and deleting files? Its 12ms (DomU) against 24ms (native) for creating a 0K file and 50ms (DomU) against 60ms (native) for creating a 10K file. Please find all the results attached. Is there any way this is possible? Maybe the communication methods used by the shared device drivers make the virtual machine think the operation has been finished successfully faster than the native way? Is there is anyone out there who can help me understanding this result? Furthermore: Is there a special recommendation for benchmarking Xen against native installations? I liked lmbench so far since it puts the focus on basic operations... what are your favourites? Is lmbench from a design perspective the wrong tool to use? I have to find some reliable results so I am really thankful for every single hint here... please feel free to email me directly as well! Thank you so much in advance! Best regards, Bjoern ____________________________________________________________________ Ihre Messenger, Communities und E-Mails jetzt in einem Programm! WEB.DE MultiMessenger http://www.produkte.web.de/messenger/?did=3071 _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hey everyone, I hope you guys can help me explaining a pretty strange result that came up when benchmarking a native Red Hat installation against a Xen DomU (installed in a file container). I used lmbench3 on a dualcore AMD-machine. To make the results comparable, I "unplugged" all CPU cores but one in the native installation (setting the "online"-entry to 0). The DomU had only one vCPU assigned. The installed packages on both machines were identical as well. After doing the initial configuration of lmbench3 I ran a script doing 10 times a "make rerun". All results seem to be OK somehow. But I cannot explain why Xen is faster than the native installation when creating and deleting files? Its 12ms (DomU) against 24ms (native) for creating a 0K file and 50ms (DomU) against 60ms (native) for creating a 10K file. Please find all the results attached. Is there any way this is possible? Maybe the communication methods used by the shared device drivers make the virtual machine think the operation has been finished successfully faster than the native way? Is there is anyone out there who can help me understanding this result? Furthermore: Is there a special recommendation for benchmarking Xen against native installations? I liked lmbench so far since it puts the focus on basic operations... what are your favourites? Is lmbench from a design perspective the wrong tool to use? I have to find some reliable results so I am really thankful for every single hint here... please feel free to email me directly as well! Thank you so much in advance! Best regards, Bjoern _______________________________________________________________________ Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 30 Tage kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=022220 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
If the virtual disc is a loopback-mounted file then the domU is probably benefitting from dom0''s buffer cache (i.e., domU is happening to exploit dom0''s memory to cache its own data). -- Keir On 3/8/08 17:51, "bbmailing@web.de" <bbmailing@web.de> wrote:> Hey everyone, > > I hope you guys can help me explaining a pretty strange result that came up > when benchmarking a native Red Hat installation against a Xen DomU (installed > in a file container). I used lmbench3 on a dualcore AMD-machine. To make the > results comparable, I "unplugged" all CPU cores but one in the native > installation (setting the "online"-entry to 0). The DomU had only one vCPU > assigned. The installed packages on both machines were identical as well. > After doing the initial configuration of lmbench3 I ran a script doing 10 > times a "make rerun". > > All results seem to be OK somehow. But I cannot explain why Xen is faster than > the native installation when creating and deleting files? Its 12ms (DomU) > against 24ms (native) for creating a 0K file and 50ms (DomU) against 60ms > (native) for creating a 10K file. Please find all the results attached. > > Is there any way this is possible? Maybe the communication methods used by the > shared device drivers make the virtual machine think the operation has been > finished successfully faster than the native way? Is there is anyone out there > who can help me understanding this result? > > Furthermore: Is there a special recommendation for benchmarking Xen against > native installations? I liked lmbench so far since it puts the focus on basic > operations... what are your favourites? Is lmbench from a design perspective > the wrong tool to use? > > I have to find some reliable results so I am really thankful for every single > hint here... please feel free to email me directly as well! > > Thank you so much in advance! > > Best regards, > Bjoern > _______________________________________________________________________ > Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 30 Tage > kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=022220 > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel