Subject: RE: [patch] prefer TSC over PM Timer
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: dean gaudet <dean-list-linux-kernel@arctic.org>
Cc: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>,
       john stultz <johnstul@us.ibm.com>, lkml <linux-kernel@vger.kernel.org>
In-Reply-To: <Pine.LNX.4.61.0411161738370.13681@twinlark.arctic.org>
References: <88056F38E9E48644A0F562A38C64FB60035C613D@scsmsx403.amr.corp.intel.com>
	 <Pine.LNX.4.61.0411161738370.13681@twinlark.arctic.org>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1100705495.32698.38.camel@localhost.localdomain>
Mime-Version: 1.0
Date: Wed, 17 Nov 2004 15:31:35 +0000
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1069
Lines: 23

On Mer, 2004-11-17 at 01:50, dean gaudet wrote:
> on a tangent... has the local apic timer ever been considered?  it's fixed 
> rate, and my measurements show it in the same performance ballpark as TSC.
> 

It would certainly work for the SMP cases which are most of the "hard"
cases where TSC breaks. This seems to be a good path to me and although
C3 would fail as has been pointed out a C3 resume is sufficiently
expensive that fixing up the tsc offset on the resume from PMTMR isn't
going to kill anyone.

> hey wait, what exactly is the problem with TSC on NUMA?  don't you just 
> need some per-cpu data (epoch and calibration) to make it work?

You have unrelated clocks that drift over time. You can't just calibrate
them.
Its different to the BP6 for example where you at least know the CPU
clocks are fixed ratio. 
-
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/