From: "Edgar E. Iglesias" <edgar.iglesias@gmail.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Jan Kiszka <jan.kiszka@siemens.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v3 0/4] Fix -icount with iothread
Date: Tue, 12 Apr 2011 23:50:14 +0200 [thread overview]
Message-ID: <20110412215014.GC8375@laped.lan> (raw)
In-Reply-To: <4DA4530F.2070905@redhat.com>
On Tue, Apr 12, 2011 at 03:26:39PM +0200, Paolo Bonzini wrote:
> On 04/12/2011 11:26 AM, Jan Kiszka wrote:
> > On 2011-04-12 10:44, Paolo Bonzini wrote:
> >> This series finally fixes -icount with iothread and avoids deadlocks
> >> due to the vm_clock not making progress when the VM is stopped.
> >> The crux of the fix is in patch 1, while patch 2 implements the
> >> "clock warping" that fixes deadlocks in v2. Clock warping uses
> >> the nanosecond resolution rt_clock timers introduced by my previous
> >> series.
> >>
> >> With this in place, patch 3 can revert the previous attempt(s).
> >> Finally, patch 4 makes the icount code clearer by finishing the
> >> bugfix/reorganization of qemu_next_deadline vs. qemu_next_alarm_deadline.
> >>
> >> v1->v2:
> >> reordered patches, renamed qemu_next_deadline
> >>
> >> v2->v3:
> >> introduced warp timer
> >>
> >> Paolo Bonzini (4):
> >> really fix -icount in the iothread case
> >> enable vm_clock to "warp" in the iothread+icount case
> >> Revert wrong fixes for -icount in the iothread case
> >> qemu_next_deadline should not consider host-time timers
> >>
> >> cpus.c | 13 ++++-
> >> qemu-common.h | 1 +
> >> qemu-timer.c | 145 ++++++++++++++++++++++++++++++++++++++++++---------------
> >> qemu-timer.h | 3 +-
> >> 4 files changed, 121 insertions(+), 41 deletions(-)
> >>
> >
> > On first glance, I've spotted a view coding style issues. Try checkpatch
> > (maybe excluding patch 3).
>
> Will repost, testing is welcome in the meanwhile!
The logic of the patches looks good to me, but it would be nice if you
could add a comment in the code regarding why we do the "warping". I think
parts of it could be based from the commit message.
I also tested the code and it works beautifully for my testcases!
iothread & icount ran faster than icount without iothread.
Thanks alot, cheers
next prev parent reply other threads:[~2011-04-13 1:46 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-12 8:44 [Qemu-devel] [PATCH v3 0/4] Fix -icount with iothread Paolo Bonzini
2011-04-12 8:44 ` [Qemu-devel] [PATCH v3 1/4] really fix -icount in the iothread case Paolo Bonzini
2011-04-12 8:44 ` [Qemu-devel] [PATCH v3 2/4] enable vm_clock to "warp" in the iothread+icount case Paolo Bonzini
2011-04-12 8:44 ` [Qemu-devel] [PATCH v3 3/4] Revert wrong fixes for -icount in the iothread case Paolo Bonzini
2011-04-12 8:44 ` [Qemu-devel] [PATCH v3 4/4] qemu_next_deadline should not consider host-time timers Paolo Bonzini
2011-04-12 9:26 ` [Qemu-devel] [PATCH v3 0/4] Fix -icount with iothread Jan Kiszka
2011-04-12 13:26 ` Paolo Bonzini
2011-04-12 21:50 ` Edgar E. Iglesias [this message]
2011-04-13 5:03 ` Paolo Bonzini
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=20110412215014.GC8375@laped.lan \
--to=edgar.iglesias@gmail.com \
--cc=jan.kiszka@siemens.com \
--cc=pbonzini@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).