All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: kurt.hackel@oracle.com,
	"Xen-Devel (E-mail)" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir.fraser@eu.citrix.com>,
	Jan Beulich <JBeulich@novell.com>
Subject: RE: rdtscP and xen (and maybe the app-tsc answer I've been looking for)
Date: Mon, 21 Sep 2009 17:11:56 -0700 (PDT)	[thread overview]
Message-ID: <8f2bf802-e080-40dc-8315-f2eea33c7926@default> (raw)
In-Reply-To: <4AB81289.8040604@goop.org>

> > Yes, I neglected an important pre-condition.  ASSUME the first
> > rdtscp on pcpu-A gets a version mismatch so that it must fetch
> > the parameters again.  Then: the vcpu switches pcpu TWICE
> > from pcpu-A to pcpu-B and back to pcpu-A and does rdtscp
> > each time on pcpu-A but reads one or more pvclock parameters
> > (that are too big to be encoded in TSC_AUX) on pcpu-B.
> >
> > I agree that this is vanishingly low probability but on
> > a pcpu-oversubscribed machine I think it only takes one
> > vcpu-to-pcpu reschedule and then a poorly timed interrupt that
> > causes the vcpu to be unscheduled, and then later rescheduled
> > on the original processor.
> >   
> 
> Sure.  It just has to keep iterating until it gets consistency.  If it
> iterates too long (10 times?  100? 1000?) it should give up and assume
> something is inherently broken.

No, I'm not talking about iteration.  In the scenario I'm
trying to describe, the version number hasn't changed on
pcpu-A so the algorithm doesn't iterate.

> On the other hand, using the tsc as part of a larger ABI 
> works reliably.
> 
> This rdtscp proposal is basically the latter, as a variant of the
> pvclock algorithm.  I'm mostly interested in it as an 
> implementation for
> vsyscall etc, rather than something that apps would use directly.
> 
> >  Unless... wait... are you assuming that
> > every unscheduled period results in an adjustment
> > of the pvclock offset parameter?  That results in
> > "nanoseconds since guest boot during which any
> > vcpu is running" rather than "nanoseconds since
> > guest boot even when all vcpus are idle", right?
> > That's different than what I had in mind, but I
> > suppose it works.
> >   
> 
> Not following you here.

I realized after I sent this that I'm not really sure
I understand the pvclock implementation, particularly
under what circumstances the version number changes
or doesn't.  And if this is different in any way
than the versions you are proposing that the app
would see.  So I'm not positive we are considering
the same cases.

Dan

  reply	other threads:[~2009-09-22  0:11 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-18 16:30 rdtscP and xen (and maybe the app-tsc answer I've been looking for) Dan Magenheimer
2009-09-18 20:27 ` Dan Magenheimer
2009-09-18 22:55   ` Jeremy Fitzhardinge
2009-09-19 15:34     ` Dan Magenheimer
2009-09-21 14:47       ` Dan Magenheimer
2009-09-21 18:36       ` Jeremy Fitzhardinge
2009-09-21 22:20         ` Dan Magenheimer
2009-09-21 22:50           ` Jeremy Fitzhardinge
2009-09-21 23:29             ` Dan Magenheimer
2009-09-21 23:55               ` Jeremy Fitzhardinge
2009-09-22  0:11                 ` Dan Magenheimer [this message]
2009-09-22  0:42                   ` Jeremy Fitzhardinge
2009-09-22 19:36                 ` Dan Magenheimer
2009-09-22 19:52                   ` Jeremy Fitzhardinge
2009-09-22 20:22                     ` Dan Magenheimer
2009-09-22 22:18                       ` Jeremy Fitzhardinge
2009-09-22  7:44               ` Jan Beulich
2009-09-22 15:00                 ` Dan Magenheimer
2009-09-22 15:16                   ` Jan Beulich
2009-09-22 17:15                     ` Jeremy Fitzhardinge
2009-09-22  7:39         ` Jan Beulich
2009-09-22 17:26           ` Jeremy Fitzhardinge
2009-09-21  8:17   ` Jan Beulich
2009-09-21 14:04     ` Dan Magenheimer
2009-09-21 14:18       ` Jan Beulich
2009-09-21 15:25         ` Dan Magenheimer
2009-09-21 15:41           ` Keir Fraser
2009-09-21 15:53             ` Keir Fraser
2009-09-21 16:55               ` Dan Magenheimer
2009-09-21 17:02                 ` Keir Fraser
2009-09-21 17:56                   ` Dan Magenheimer
2009-09-21 18:17                     ` Keir Fraser
2009-09-21 21:47                       ` Dan Magenheimer
2009-09-21 16:03           ` Jan Beulich

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=8f2bf802-e080-40dc-8315-f2eea33c7926@default \
    --to=dan.magenheimer@oracle.com \
    --cc=JBeulich@novell.com \
    --cc=jeremy@goop.org \
    --cc=keir.fraser@eu.citrix.com \
    --cc=kurt.hackel@oracle.com \
    --cc=xen-devel@lists.xensource.com \
    /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.