Bug 690267

Summary: Backport qemu_get_ram_ptr() performance improvement
Product: Red Hat Enterprise Linux 6 Reporter: Alex Williamson <alex.williamson>
Component: qemu-kvmAssignee: Alex Williamson <alex.williamson>
Status: CLOSED ERRATA QA Contact: Virtualization Bugs <virt-bugs>
Severity: low Docs Contact:
Priority: unspecified    
Version: 6.1CC: ehabkost, juzhang, michen, mkenneth, shu, tburke, virt-maint
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: qemu-kvm-0.12.1.2-2.153.el6 Doc Type: Bug Fix
Doc Text:
Cause: qemu_get_ram_ptr() performance suboptimal. 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 now smaller.
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-05-19 11:20:58 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 580953    

Description Alex Williamson 2011-03-23 18:27:06 UTC
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

Comment 1 juzhang 2011-03-24 07:41:19 UTC
> 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

Comment 2 Alex Williamson 2011-03-24 16:58:04 UTC
(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.

Comment 8 Shaolong Hu 2011-04-07 10:04:35 UTC
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.

Comment 9 Eduardo Habkost 2011-05-03 19:01:14 UTC
    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.

Comment 10 Eduardo Habkost 2011-05-03 19:03:21 UTC
    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.

Comment 11 errata-xmlrpc 2011-05-19 11:20:58 UTC
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

Comment 12 errata-xmlrpc 2011-05-19 13:02:31 UTC
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