Date: Tue, 21 Oct 2008 19:40:08 +0200
From: Andi Kleen <andi@firstfloor.org>
To: Alok Kataria <akataria@vmware.com>
Cc: Andi Kleen <andi@firstfloor.org>, "H. Peter Anvin" <hpa@zytor.com>,
       LKML <linux-kernel@vger.kernel.org>,
       the arch/x86 maintainers <x86@kernel.org>,
       Daniel Hecht <dhecht@vmware.com>
Subject: Re: [PATCH 0/3] Improve TSC as a clocksource under VMware
Message-ID: <20081021174008.GH12825@one.firstfloor.org>
References: <1224552902.2640.88.camel@alok-dev1> <874p36fflp.fsf@basil.nowhere.org> <1224607284.6161.22.camel@alok-dev1>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1224607284.6161.22.camel@alok-dev1>
User-Agent: Mutt/1.4.2.1i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1740
Lines: 42

> > It would be far nicer if VMware just emulated the "constant_tsc" bit
> > in the AMD CPUID leaf, instead of adding all that gunk to Linux.
> > Right now it's only checked for AMD CPUs, but that could be changed.
> 
> I am not sure if we might want to skip the tsc_sync code for all the
> cpus which have this constant_tsc bit set, can we ?

It should be ok, although normally sanity checks should be kept.

> Since i have seen that we can have cases where tsc is marked unstable as
> its not found to be perfectly stable between cpus, we have to make sure
> that we avoid this check when on VMware. Even with slight difference in

Normally tsc sync should only fail when the error is large.
It cannot detect very small derivation by design. It's more like
a sanity check "does the TSC sync look half way sane"

If it fails on VMware perhaps the margins are not big enough or 
something else is fishy.

But still it could be skipped with constant_tsc. But again you
shouldn't really fail that check -- if you do fail are you
sure your clock is really synchronized enough that there
are no observable differences?

> TSC between cpus, we know that TSC is the best available clocksource as
> the hypervisor (VMware) makes sure that the drift is always marginal (if
> ever there is).

The drift has to be unobservable, otherwise you still risk
non monotonity.  Also when there is drift it has to be short
term only, otherwise it would accumulate over longer times.

-Andi

-- 
ak@linux.intel.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/