RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 690267 - Backport qemu_get_ram_ptr() performance improvement
Summary: Backport qemu_get_ram_ptr() performance improvement
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: qemu-kvm
Version: 6.1
Hardware: Unspecified
OS: Unspecified
unspecified
low
Target Milestone: rc
: ---
Assignee: Alex Williamson
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks: 580953
TreeView+ depends on / blocked
 
Reported: 2011-03-23 18:27 UTC by Alex Williamson
Modified: 2013-01-09 23:41 UTC (History)
7 users (show)

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.
Clone Of:
Environment:
Last Closed: 2011-05-19 11:20:58 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2011:0534 0 normal SHIPPED_LIVE Important: qemu-kvm security, bug fix, and enhancement update 2011-05-19 11:20:36 UTC

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
Note You need to log in before you can comment on or make changes to this bug.