From: Peter Portante <peter.portante@redhat.com>
To: qemu-devel@nongnu.org
Cc: Peter Portante <pportant@redhat.com>
Subject: [Qemu-devel] [PATCH v2] qemu-timer.c: Remove 250us timeouts
Date: Thu, 5 Apr 2012 11:00:45 -0400 [thread overview]
Message-ID: <1333638045-20806-1-git-send-email-peter.portante@redhat.com> (raw)
Basically, the main wait loop calls qemu_run_all_timers() unconditionally. The
first thing this routine used to do is to see if a timer had been serviced,
and then reset the loop timeout to the next deadline.
However, the new deadlines had not been calculated at that point, as
qemu_run_timers() had not been called yet for each of the clocks. So
qemu_rearm_alarm_timer() would end up with a negative or zero deadline, and
default to setting a 250us timeout for the loop.
As qemu_run_timers() is called for each clock, the real deadlines would be put
in place, but because a loop timeout was already set, the loop timeout would
not be changed.
Once that 250us timeout fired, the real deadline would be used for the
subsequent timeout.
For idle VMs, this effectively doubles the number of times through the loop,
doubling the number of select() system calls, timer calls, etc. putting added
scheduling pressure on the kernel. And under cgroups, this really causes a big
problem because the cgroup code does not scale well.
By simply running the timers before trying to rearm the timer, we always rearm
with a non-zero deadline, effectively halving the number of system calls.
Signed-off-by: Peter Portante <pportant@redhat.com>
---
qemu-timer.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/qemu-timer.c b/qemu-timer.c
index d7f56e5..b0845f1 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -472,16 +472,16 @@ void qemu_run_all_timers(void)
{
alarm_timer->pending = 0;
+ /* vm time timers */
+ qemu_run_timers(vm_clock);
+ qemu_run_timers(rt_clock);
+ qemu_run_timers(host_clock);
+
/* rearm timer, if not periodic */
if (alarm_timer->expired) {
alarm_timer->expired = 0;
qemu_rearm_alarm_timer(alarm_timer);
}
-
- /* vm time timers */
- qemu_run_timers(vm_clock);
- qemu_run_timers(rt_clock);
- qemu_run_timers(host_clock);
}
#ifdef _WIN32
--
1.7.7.6
reply other threads:[~2012-04-05 15:01 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1333638045-20806-1-git-send-email-peter.portante@redhat.com \
--to=peter.portante@redhat.com \
--cc=pportant@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).