Red Hat Bugzilla – Bug 690267
Backport qemu_get_ram_ptr() performance improvement
Last modified: 2013-01-09 18:41:58 EST
Description of problem: A trivial performance improvement was posted upstream for qemu_get_ram_ptr() which makes us skip doing some qlist manipulation if the found ramblock is already the first in the list. Submitter claims it drops a few % off the time spent in this function during VM boot. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: qemu.git commit 7d82af38b78305155553013c6fd709dc50404199
> Submitter claims it drops a few % off the time > spent in this function during VM boot. Hi,Alex Would you please provide efficiently way test this issue? Just compare with time-consuming on VM boot between between fixed version(after applied this patch) and un-fixed version(before applied this patch)?if yes,how much? thanks
(In reply to comment #1) > > Submitter claims it drops a few % off the time > > spent in this function during VM boot. > Hi,Alex > > Would you please provide efficiently way test this issue? > > Just compare with time-consuming on VM boot between between fixed > version(after applied this patch) and un-fixed version(before applied this > patch)?if yes,how much? thanks The upstream reporter claimed a drop from 6.3% to 2.1% in cpu time consumed by qemu_get_ram_ptr during guest boot for *emulating ARM on x86_64*. I imagine he did this by running oprofile on the qemu process while booting. We should expect to see a much, much smaller improvement with kvm enabled. If you want to run oprofile on a guest boot, just look to see that if qemu_get_ram_ptr takes any time, that it's reduced after the patch is applied.
Oprofile Results: Since sample amount of qemu_get_ram_ptr during guest boot varies, test 3 times each. ------------------------------------------------------------------------------- Host: 2.6.32-128.el6.x86_64 qemu-kvm-0.12.1.2-2.154.el6.x86_64 CPU: Core 2, speed 2000 MHz (estimated) Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (Unhalted core cycles) count 750000 samples % image name symbol name ... 2 0.1412 qemu-kvm qemu_get_ram_ptr 3 0.2062 qemu-kvm qemu_get_ram_ptr 3 0.1887 qemu-kvm qemu_get_ram_ptr ------------------------------------------------------------------------------- Host: 2.6.32-128.el6.x86_64 qemu-kvm-0.12.1.2-2.152.el6.x86_64 CPU: Core 2, speed 2000 MHz (estimated) Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (Unhalted core cycles) count 750000 samples % image name symbol name ... 10 0.6775 qemu-kvm qemu_get_ram_ptr 9 0.5933 qemu-kvm qemu_get_ram_ptr 10 0.6959 qemu-kvm qemu_get_ram_ptr Conclusion: -------------- The patch does reduce cpu time consumed by qemu_get_ram_ptr during guest boot, despite we don't emulating ARM on x86_64, verified.
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Cause: qemu_get_ram_ptr() performance suboptimal. Consequence: VM boot times incrased. Fix: patch to make qemu_get_ram_ptr() skip doing some qlist manipulation if the found ramblock is already the first in the list. Consequence: VM boot times are smaller.
Technical note updated. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1,7 +1,7 @@ Cause: qemu_get_ram_ptr() performance suboptimal. -Consequence: VM boot times incrased. +Consequence: higher use of CPU inside qemu_get_ram_ptr() during VM boot. Fix: patch to make qemu_get_ram_ptr() skip doing some qlist manipulation if the found ramblock is already the first in the list. -Consequence: VM boot times are smaller.+Consequence: VM boot times are now smaller.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2011-0534.html