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 912763 - RFE: reduce wakeups per second
Summary: RFE: reduce wakeups per second
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: spice
Version: 7.2
Hardware: x86_64
OS: Linux
low
low
Target Milestone: pre-dev-freeze
: 7.3
Assignee: Default Assignee for SPICE Bugs
QA Contact: SPICE QE bug list
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-02-19 15:45 UTC by Phil Knirsch
Modified: 2016-02-17 08:38 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-02-17 08:38:37 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Phil Knirsch 2013-02-19 15:45:40 UTC 
Description of problem:

After installing Fedora 18 in a virt guest i noticed the lacking graphics performance and followed the advice of one of our qemu guys here to switch to Spice and qxl instead of the default VNC and cirrus drivers.

While the graphics performance is really a lot better now i noticed a drastic increase in wakeups per second in idle mode for any guest where i enable Spice the Spice display server. It doesn't matter if i use qxl or cirrus video driver afterwards, just switching from VNC to Spice does that.

I've tried this with a Fedora 18 guest and a RHEL-6.3 guest and both show the same effect:

Powertop snippet for qemu-kvm wakeups with VNC display server and a running RHEL-6.3 guest:
Top causes for wakeups:
   0.5% (  7.4)          qemu-kvm : hrtimer_start (kvm_timer_fn)
   0.4% (  6.0)          qemu-kvm : hrtimer_start_range_ns (posix_timer_fn)

Powertop snippet for qemu-kvm wakeups with SPICE display server and a running RHEL-6.3 guest:
Top causes for wakeups:
   7.0% (130.2)          qemu-kvm : hrtimer_start_range_ns (posix_timer_fn)
   0.5% (  9.3)          qemu-kvm : hrtimer_start (kvm_timer_fn)


I've straced both runs and the SPICE one shows very regular select() wakeups and successfull read() and write() calls following that from anon inodes and some pipes whereas the VNC one sites really idle there, resp. only does approx 1 wakeup every 100ms.

Version-Release number of selected component (if applicable):

Host: RHEL-6.3 with current packages
spice-server-0.10.1-10.el6.x86_64
qemu-kvm-0.12.1.2-2.295.el6_3.10.x86_64
libvirt-0.9.10-21.el6_3.8.x86_64
kernel-2.6.32-279.22.1.el6.x86_64
glibc-2.12-1.80.el6_3.7.x86_64

Guests: Fedora 18 base install & RHEL-6.3 base install

How reproducible:

Always

Steps to Reproduce:
1. Default install virt guest (Fedora or RHEL) using VNC
2. Start guest and run powertop
3. Note down wakeups per second from qemu-kvm
4. Stop guest and change display server from VNC to SPICE
5. Repeat step 2 and 3

Expected results:

Simply switching to SPICE shouldn't add over 120 wakeups per second in idle mode.

If you need any more info just let me know.

Thanks & regards, Phil
Comment 2 RHEL Program Management 2013-02-23 06:47:37 UTC 
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.
Comment 4 RHEL Program Management 2013-10-14 04:14:44 UTC 
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.
Comment 5 Marc-Andre Lureau 2014-06-18 18:50:59 UTC 
until the display is not completely idle, spice worker will attempt to read every 10ms, that's 100x/s. You should be able to see that with qemu trace_qxl_ring_command_check. I don't know what's the design rationale behind this. Gerd, Alon, any idea?

I think this is not 6.6 material anymore, moving to 6.7
Comment 6 Gerd Hoffmann 2014-06-19 08:04:37 UTC 
(In reply to Marc-Andre Lureau from comment #5)
> until the display is not completely idle, spice worker will attempt to read
> every 10ms, that's 100x/s. You should be able to see that with qemu
> trace_qxl_ring_command_check. I don't know what's the design rationale
> behind this. Gerd, Alon, any idea?

The idea is probably to reduce the guest/host notification overhead, especially as spice server runs in its own thread.  When the display has been idle for a while (no commands arrived for half a second IIRC) spice-server stops polling and asks qxl for a notification though.

It is certainly possible to try tweak those values (poll interval, idle delay).
Maybe also try making the poll interval adaptive to screen update rate.
Maybe make spice-server behave differently depending on whenever a spice client is connected or not.

But after all the fundamental question is why the display isn't idle.
Do you boot to gdm?  Anying constantly updating on your screen?
Or text console?  On the text console the friendly blinking cursor will keep spice-server busy (until the screen saver kicks in, after 10 minutes by default).
Comment 8 Marc-Andre Lureau 2014-11-04 11:31:26 UTC 
This patch removes ~30 wakeups / sec in qemu: 
"console: remove refresh timer when using spice & QXL mode"

This patch removes ~30 wakeups / sec in spice server: 
http://lists.freedesktop.org/archives/spice-devel/2014-November/017802.html

With those 2 patches, I get down to about ~10 wakeups per second according to powertop.
Comment 9 Marc-Andre Lureau 2014-11-04 11:33:43 UTC 
I think we should consider moving this bug to upstream bug tracker.
Comment 11 David Jaša 2015-03-10 09:42:11 UTC 
One-time change, no test case needed.
Comment 13 Christophe Fergeau 2015-09-03 07:32:06 UTC 
(In reply to Marc-Andre Lureau from comment #8)
> This patch removes ~30 wakeups / sec in qemu: 
> "console: remove refresh timer when using spice & QXL mode"
> 

Discussed in https://lists.nongnu.org/archive/html/qemu-devel/2014-11/msg00624.html
Superseded by https://lists.gnu.org/archive/html/qemu-devel/2014-11/msg00625.html
This series was pushed as
http://git.qemu.org/?p=qemu.git;a=commit;h=0b2824e5
http://git.qemu.org/?p=qemu.git;a=commit;h=3dcadce5


> This patch removes ~30 wakeups / sec in spice server: 
> http://lists.freedesktop.org/archives/spice-devel/2014-November/017802.html
> 

This was committed as http://cgit.freedesktop.org/spice/spice/commit/?id=c541d7e29d
See also http://cgit.freedesktop.org/spice/spice/commit/?id=697f3214fd1

> With those 2 patches, I get down to about ~10 wakeups per second according
> to powertop.
Comment 14 David Blechter 2015-10-26 19:59:46 UTC 
required patches in QEMU as well. 

Minor improvement, best to be fixed in rhel 7. Moving to rhel 7.3
Comment 16 Frediano Ziglio 2016-02-17 08:38:37 UTC 
Fixed in master branch.
Note You need to log in before you can comment on or make changes to this bug.