Re: [Xen-devel] [PATCH v9] new config option vtsc_tolerance_khz to avoid TSC emulation

[Ian Jackson <ian.jackson@xxxxxxxxxx>]

Olaf Hering writes ("Re: [PATCH v9] new config option vtsc_tolerance_khz to 
avoid TSC emulation"):
> Am Thu, 13 Sep 2018 09:39:13 +0200
> schrieb Olaf Hering <olaf@xxxxxxxxx>:
> > this patch was not applied yet, even after a few "pings".
> 
> No reaction since months.
> So scrap that patch, just in case it is still part of someones to-consider 
> queue.

I think it would be worth exploring whether this patch could be
applied without an explicit ack from Andrew.

I confess I ignored all the previous mails because they all started
   Andrew,
or
   Andrew, Lars,
so I assumed that you didn't want attention from other
maintainers/committers.

Now that I look at the thread it is difficult for me to see the wood
for the trees but I don't see unanswered concerns.  I guess the patch
should maybe therefore be committed.

As committer, before I did that despite a missing ack, I would want to
(i) try to understand if possibly why the ack was missing (ii) do my
own review to satisfy any doubts (iii) give the maintainer a clear
tike interval to say "nack".


As for (i) (reasons for lack of ack), see above, and it's not clear to
me; but AFAICT there are two difficulties.  One (see (a) below) is
with the principle of the feature.  One (see (b) below) is about a
detail of the implementation.

As for (ii) (own review), see below.  That addresses (a) and (b).

As for (iii): If anyone actually objects to this patch for some
different reason, or to my proposed approach, please comment in the
next 7 days.


(a) Principle

I read the documentation for the new feature and it seems to make
sense.  But it would be nice for the documentation to explain what is
considered a likely safe and sufficient value.

For example, one might say something like this:

  Typical TSC speed variation between supposedly identical hosts is
  about X%.  A Unix guest running NTP for time synchronisation can
  cope with clock drift rates of up to about Y%.  So a
  vtsc_tolerance_khz setting between these two values is likely to be
  effective for migration between "identical" hosts, and not
  disruptive.

Olaf, please could you fill in the blanks in that text, and consider
what the exact wording should be (depending on what research you
conducted etc.), and then consider whether to put it in the
documentation, commit meesage, or just on the mailing list ?

Personally I think documentation would be ideal if we have firm
information but if firm information is hard to come by and all we have
is empirical data, then maybe a commit message describing those
experiences would be sufficient.


(b) Protocol compatibility

  Olaf:
  > > On 07.06.18 at 16:49, <olaf@xxxxxxxxx> wrote:
  > > > Am Thu, 07 Jun 2018 08:44:41 -0600
  > > > schrieb "Jan Beulich" <JBeulich@xxxxxxxx>:
  > > >> The re-use of the field is acceptable only if all existing
  > > >> senders reliably fill zero in there.
  > > >
  > > > How do we know all senders? I just know about write_tsc_info
  > > > from xen-4.6+.
  > >
  > > I don't think we care about senders other than ones using libxc, so
  > > by knowing whether all libxc versions conform to the requirement,
  > > we could declare we're fine.
  > 
  > Yes, I think we are fine. And if migration from pre-4.6 is supported
  > anyway is another question. Most likely the answer is no.

This comment from Olaf "Yes, I think we are fine" is not particularly
reassuring.  Olaf, can you please say something more definite about
how you verified whether your assertion is true.

And yes, we do mean also for versions from pre-4.6.  It is not
supported, but it must not go wrong in unexpected ways.  You can use
the git history to see older implementations in libxc.


Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel