> > Jul 11 21:23:35 gradient kernel: CPU 2: Syncing TSC to CPU 0.
> > Jul 11 21:23:35 gradient kernel: CPU 2: synchronized TSC with CPU 0
> > (last diff -91 cycles, maxerr 621 cycles)
>
> > Jul 11 21:23:35 gradient kernel: CPU 3: Syncing TSC to CPU 0.
> > Jul 11 21:23:35 gradient kernel: CPU 3: synchronized TSC with CPU 0
> > (last diff -122 cycles, maxerr 1129 cycles)
>
> This means the CPUs diverged between 500 and 1100 cycles in the night.
> This can already cause severe timing problems with the clock
> going backwards if a task switches CPUs - and there are many
> programs that don't like that. If the system is up longer it
> will be worse.
Joachim -
Can you run Andi's test without changing PN! frequency?
I'd like to see a baseline for how bad TSC is by itself,
and whether the TSCnow! code is making the problem worse
or better.
Customers in the field seem to want to use TSC for gtod,
so I want to know how awful an idea that is.
> The only way to possibly make the concept work would be
> regular TSC resyncs during runtime, but I think I would
> prefer using per CPU TSC offsets using RDTSCP instead because
> they should be able to tolerate arbitary shifts.
I would prefer that, too, but I don't have the resources
to code that solution in the timeframe I have available.
-Mark Langsdorf
AMD, Inc.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
