All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.