On Fri, 2007-05-25 at 11:16 -0700, Dave Hansen wrote:
> On Fri, 2007-05-25 at 10:41 +0200, Ingo Molnar wrote:
> > * William Lee Irwin III <[email protected]> wrote:
> > > > yes, that's what i meant under 'slightly async'. Some AMD CPUs are
> > > > like that too and sched_clock() now handles that fine. So we should
> > > > try my patch.
> > >
> > > Sorry, then. I took slight to mean something else. In any event I was
> > > only quantifying things. I've no opinion whatsoever on the impact of
> > > the code on NUMA-Q, only some recall of its operating characteristics.
> >
> > there's no need to apologize at all! Thanks for reminding us about the
> > time-scale and nature of the TSC drift on NUMAQ. I was worried that
> > maybe the TSC was totally unusable for some reason - but that's
> > fortunately not the case. So we now have one quirk less, hopefully :-)
>
> Last I remember, it was totally useless for timekeeping, but was useful
> for cpu-local time measurements.
>
> John, it's still useless for time, right? Does sched_clock() really fix
> it?
Yea, on multi-node NUMAQ the TSC shouldn't be used for timekeeping.
However it should be fine for sched_clock(), or other cpu-local
measurements as the TSCs are constant (no cpufreq, no deep sleep
states).
-john
-
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]
