qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Victor Clement <victor.clement@openwide.fr>
To: qemu-devel@nongnu.org
Cc: "françois Guerret" <francois.guerret@hotmail.fr>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Julien Viard de Galbert" <julien.viarddegalbert@openwide.fr>
Subject: Re: [Qemu-devel] [PATCH 1/3] icount: implement a new icount_no_rt mode without real time cpu sleeping
Date: Fri, 29 May 2015 10:59:07 +0200 (CEST)	[thread overview]
Message-ID: <1155201608.740003.1432889947235.JavaMail.root@openwide.fr> (raw)
In-Reply-To: <5565BDF0.8050508@redhat.com>

----- Mail original -----
> De: "Paolo Bonzini" <pbonzini@redhat.com>
> À: "Victor CLEMENT" <victor.clement@openwide.fr>, qemu-devel@nongnu.org
> Cc: "francois guerret" <francois.guerret@hotmail.fr>
> Envoyé: Mercredi 27 Mai 2015 14:52:00
> Objet: Re: [Qemu-devel] [PATCH 1/3] icount: implement a new icount_no_rt mode without real time cpu sleeping
> 
> 
> 
> On 27/05/2015 13:52, Victor CLEMENT wrote:
> > In this new icount_no_rt mode, the QEMU_VIRTUAL_CLOCK runs at the
> > maximum possible speed by warping the sleep times of the virtual
> > cpu to the
> > soonest clock deadline. The virtual clock will be updated only
> > according
> > the instruction counter.
> > 
> > Signed-off-by: Victor CLEMENT <victor.clement@openwide.fr>
> > ---
> >  cpus.c | 64
> >  ++++++++++++++++++++++++++++++++++++++++------------------------
> >  1 file changed, 40 insertions(+), 24 deletions(-)
> > 
> > diff --git a/cpus.c b/cpus.c
> > index de6469f..012d14b 100644
> > --- a/cpus.c
> > +++ b/cpus.c
> > @@ -105,6 +105,7 @@ static bool all_cpu_threads_idle(void)
> >  
> >  /* Protected by TimersState seqlock */
> >  
> > +static bool icount_no_rt;
> 
> It is somewhat hard to read the code due to double negations.  What
> about "-icount sleep=[yes|no]" and naming the variable
> "icount_sleep"?

You are right, the "nort" can be ambiguous. icount_sleep seems clear.
Thanks for the suggestion.

> [...]
> > +        if (icount_no_rt) {
> > +            /*
> > +             * We never let VCPUs sleep in async icount mode.
> 
> s/async icount/sleep=no/
> 
> ?

Right ! My bad...

> 
> Otherwise the series looks good.
> 
> Paolo

Ok, I sumbit the v2 with icount_sleep naming.

Victor

> 
> > +             * If there is a pending QEMU_CLOCK_VIRTUAL timer we
> > just advance
> > +             * to the next QEMU_CLOCK_VIRTUAL event and notify it.
> > +             * It is useful when we want a deterministic execution
> > time,
> > +             * isolated from host latencies.
> > +             */
> > +            seqlock_write_lock(&timers_state.vm_clock_seqlock);
> > +            timers_state.qemu_icount_bias += deadline;
> > +            seqlock_write_unlock(&timers_state.vm_clock_seqlock);
> > +            qemu_clock_notify(QEMU_CLOCK_VIRTUAL);
> > +        } else {
> > +            /*
> > +             * We do stop VCPUs and only advance
> > QEMU_CLOCK_VIRTUAL after some
> > +             * "real" time, (related to the time left until the
> > next event) has
> > +             * passed. The QEMU_CLOCK_VIRTUAL_RT clock will do
> > this.
> > +             * This avoids that the warps are visible externally;
> > for example,
> > +             * you will not be sending network packets
> > continuously instead of
> > +             * every 100ms.
> > +             */
> > +            seqlock_write_lock(&timers_state.vm_clock_seqlock);
> > +            if (vm_clock_warp_start == -1 || vm_clock_warp_start >
> > clock) {
> > +                vm_clock_warp_start = clock;
> > +            }
> > +            seqlock_write_unlock(&timers_state.vm_clock_seqlock);
> > +            timer_mod_anticipate(icount_warp_timer, clock +
> > deadline);
> >          }
> > -        seqlock_write_unlock(&timers_state.vm_clock_seqlock);
> > -        timer_mod_anticipate(icount_warp_timer, clock + deadline);
> >      } else if (deadline == 0) {
> >          qemu_clock_notify(QEMU_CLOCK_VIRTUAL);
> >      }
> > 
> 
>

  reply	other threads:[~2015-05-29  8:59 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-27 11:52 [Qemu-devel] [PATCH 0/3] implement a new icount_no_rt mode Victor CLEMENT
2015-05-27 11:52 ` [Qemu-devel] [PATCH 1/3] icount: implement a new icount_no_rt mode without real time cpu sleeping Victor CLEMENT
2015-05-27 12:52   ` Paolo Bonzini
2015-05-29  8:59     ` Victor Clement [this message]
2015-05-27 11:52 ` [Qemu-devel] [PATCH 2/3] icount: add rt parameter to the -icount option to toogle icount_no_rt mode Victor CLEMENT
2015-05-27 11:52 ` [Qemu-devel] [PATCH 3/3] icount: print a warning if there is no more deadline in no_rt mode Victor CLEMENT
2015-05-27 12:52 ` [Qemu-devel] [PATCH 0/3] implement a new icount_no_rt mode Paolo Bonzini
2015-05-29  8:54   ` Victor Clement
2015-05-29 11:14     ` Paolo Bonzini
2015-05-29 15:06       ` Victor Clement

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=1155201608.740003.1432889947235.JavaMail.root@openwide.fr \
    --to=victor.clement@openwide.fr \
    --cc=francois.guerret@hotmail.fr \
    --cc=julien.viarddegalbert@openwide.fr \
    --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).