Re: Dual core Athlons and unsynced TSCs

[Lee Revell <rlrevell@joe-job.com>]

On Sun, 2006-01-15 at 10:21 -0800, thockin@hockin.org wrote:
> On Sun, Jan 15, 2006 at 11:33:36AM -0500, Lee Revell wrote:
> > On Sun, 2006-01-15 at 08:25 -0800, thockin@hockin.org wrote:
> > > On Sun, Jan 15, 2006 at 01:52:44AM -0700, Zan Lynx wrote:
> > > > A laptop user could also bind a process to a single CPU, and use the
> > > > scaling min/max values to lock CPU speed to a single value.  The TSC may
> > > > still stop during HLT, but software must be handling that already.
> > > > 
> > > > Wouldn't that provide an accurate TSC?
> > > 
> > > monotonic but not linear.  Also remember that the OS will use rdtsc here
> > > and there, and you can't affine the OS :)
> > > 
> > 
> > So the options are either to fix the TSC handling on these systems (by
> > resyncing the TSCs when exiting from HLT), or eliminate the use of rdtsc
> > by the OS?
> 
> Or both.  You can trap rdtsc users in userland, you have to manually audit
> kernel users.
> 
> It should be abolished or properly wrapped in kernel code, as soon as a
> resync path is available.
> 

For the purposes of this discussion I was not considering direct use of
rdtsc from userland for timing, I've accepted the arguments that this is
a lost cause with today's hardware (although I maintain it was viable in
practice on previous generations of hardware).  Besides, rdtsc is
useless from userspace if the kernel traps it, because the whole point
of using it over gettimeofday() was that it was dirt cheap.

I'm content to make sure the kernel's internal timekeeping is solid.

Lee

-
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/