similar to: [IA64] Weekly benchmark results [ww49]

Hi, I report a benchmark result of this week on IPF using ia64/xen-unstable and ia64/linux-2.6.18-xen. All test cases passed. TEST ENVIRONMENT Machine : Tiger4 Kernel : 2.6.18.8-xen Changeset : 18872:3acca92b9597 (ia64/xen-unstable) 753:17adc5c344fe (ia64/linux-2.6.18-xen) 131:9210bd27a551 (efi-vfirmware) b4d410a

Hi, I report a benchmark result of this week on IPF using ia64/xen-unstable and ia64/linux-2.6.18-xen. All test cases passed. TEST ENVIRONMENT Machine : Tiger4 Kernel : 2.6.18.8-xen Changeset : 17133:daf39fc8038a (ia64/xen-unstable) 442:0c1e6a1b8e90 (ia64/linux-2.6.18-xen) 70:b6ea2d6130fb (efi-vfirmware) Dom0 OS : RHEL4

Hi, I report a benchmark result of this week on IPF using ia64/xen-unstable and ia64/linux-2.6.18-xen. All test cases passed. TEST ENVIRONMENT Machine : Tiger4 Kernel : 2.6.18.8-xen Changeset : 18503:325904748847 (ia64/xen-unstable) 673:3161879fdf22 (ia64/linux-2.6.18-xen) 126:d255b2cfdd5a (efi-vfirmware) 0f3d638

Hi, I report a benchmark result of this week on IPF using ia64/xen-unstable and ia64/linux-2.6.18-xen. Building the xen-vnif PV-on-HVM driver failed. This issue has already fixed on staging trees by the following patches: http://xenbits.xensource.com/staging/xen-unstable.hg?rev/48c8244c47c7 http://xenbits.xensource.com/staging/linux-2.6.18-xen.hg?rev/670f8d5305d2 In LTP, test cases related

Hi, I report a benchmark result of this week on IPF using xen-ia64-unstable. I did not test a VT-i domain because compiling PV-on-HVM drivers failed. In LTP, test cases related with direct IO still failed. # dio02 dio03 dio06 dio08 dio09 dio12 dio14 dio15 dio17 dio18 dio19 # dio21 dio22 dio23 dio25 dio26 dio27 dio28 And syslog10 failed but passed manually. TEST ENVIRONMENT Machine

Hi, I report a benchmark result of this week on IPF using xen-ia64-unstable. I did not test a VT-i domain because linking PV-on-HVM drivers still failed. In LTP, test cases related with direct IO still failed. # dio02 dio03 dio06 dio08 dio09 dio12 dio14 dio15 dio17 dio18 dio19 # dio21 dio22 dio23 dio25 dio26 dio27 dio28 TEST ENVIRONMENT Machine : Tiger4 Kernel :

Hi all, Sorry for the delay. This implements binary patching of call sites for interrupt-related paravirt ops, since no-doubt Andi wasn't the only one to believe this approach is slow. The benchmarks were done on a UP 3GHz Pentium 4 with 512MB of RAM. 2.6.17-rc4 vs 2.6.17-rc4 with CONFIG_PARAVIRT=y vs 2.6.17-rc4 CONFIG_PARAVIRT=y with patch. Summary: with binary patching, the difference

Hi all, Sorry for the delay. This implements binary patching of call sites for interrupt-related paravirt ops, since no-doubt Andi wasn't the only one to believe this approach is slow. The benchmarks were done on a UP 3GHz Pentium 4 with 512MB of RAM. 2.6.17-rc4 vs 2.6.17-rc4 with CONFIG_PARAVIRT=y vs 2.6.17-rc4 CONFIG_PARAVIRT=y with patch. Summary: with binary patching, the difference

>From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk] >Sent: 2006年5月22日 17:51 >To: Keir Fraser > >>> We just need to reverse the whole change for ia64, since both >domU >>> and domVTI are insert a hole by this auto-balloon patch. Due to >>> missing balloon support on xen/ia64 as you said, both domU and >domVTI >>> failed due to this change.

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

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

Hi, This patch adds more user registers to show them to xenctx for ia64. Tested domU/domVTi on ia64. Sample is the below. # ./xenctx 1 0 iip: e000000000000810 ipsr: 00001012087a6010 b0: a000000100068a70 b6: a00000010014ff60 b7: e000000000000800 cr_ifs: 800000000000050a ar_unat:

Hi, Xiantao >+3. Get Guest Firmware named as Flash.fd, and put it under right place: >+ (1) If you have the guest firmware (binary)released by Intel >Corp for Xen, you can use it directly. >+ (2) If you want to build a guest firmware form source code. >Please download the source from >+ hg clone >http://xenbits.xensource.com/ext/efi-vfirmware.hg >+ Use the Guide of the

Hi all, I''ve performed a benchmark on my server to compare performance with and without Xen, and with and without domUs active. I used lmbench to measure basic hardware operations on math and memory, and system calls like mmap(), fork(), exec(). The results are at http://drainbamage.nl/2009/04/05/xen-benchmark/ . It seems that Xen adds significant overhead to process creation

Package: xen-utils-3.2-1 Severity: grave Hi, maintainer! This message about the error concerns a few packages at once. I've tested all the packages (for Lenny) on my Debian mirror. All scripts of packages (marked as executable) were tested. In some packages I've discovered scripts with errors which may be used by a user for damaging important system files or user's files. For

The patched attached enables x86_64 xenlinux with "late pin, early unpin", which is already implemented for x86_32. Since we now only pin the root rather than any of the other levels, the overall performance became better especially with workloads that require heavy memory management operations. On 8-way x86_64 xenlinux (dom0) the kernel build was improved by about 10% (using make

Hi, I have used lmbench to test the performance of Xenolinux (HVM) CPU: Intel (R) Core (TM)2 T7400@2.16GHz Memory size: 1GB NIC: Intel PCIe Gigabit LAN chip HD: Samsung 80GB/7200rpm/8M Dom0: 2.6.19-1.2911.6.5.fc6xen DomU: 2.6.20-1.2944.fc6 The context switch time seems saturated along with increasement of processes? e.g. size of processes 64kB N=number of process t=context switch time when

At OLS I gave a talk on some of the Xen scalability inhibitors, and one of these was writable page tables. We went over why the feature does not scale, but just as important, we found that the uniprocessor case does not provide any advantage either. These tests were done on x86_64, so I wanted to run the 1-way test on 32 bit to show the same problem. So, I have run with writable PTs and

Hi all, Currently we have severe problem and are struggling to investigate it. The problem is data broken. Reproduce pocess is following, 0. test FTP function between guest domain and FTP client(other PC). 1. put data from FTP client to guest domain. 2. get data from guest domain to FTP client. 3. compare put data and get data on FTP client. 4. repeat process from step1 to step3.

Hi, until recently, the hvm guest firmware for xen-ia64 was a private binary file owned and delivered by Intel. I have written an open-source implementation based on tianocore.org. The ia64 firmware is roughly speaking EFI. I have also ported tianocore to Qemu/x86. It shouldn''t be hard to port it to x86. Because the sources are big (at least 40MB) and the buildery is not easy (build