lkml.org 
[lkml]   [2015]   [Apr]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v1] watchdog: Use a reference cycle counter to avoid scaling issues
On Thu, 23 Apr 2015, Andi Kleen wrote:
> > We can just detect the deviation in the callback itself:
> >
> > u64 now = ktime_get_mono_fast_ns();
> >
> > if (now - __this_cpu_read(nmi_timestamp) < period)
> > return;
> >
> > __this_cpu_write(nmi_timestamp, now);
> >
> > It's that simple.
>
> It's a simple short term hac^wsolution.

Yes, and way simpler and less complex for pushing into stable.

> But if we had a (hypothetical) system with let's say 10*TSC max you
> may end up with quite a few false ticks, as in unnecessary
> interrupts. With 100*TSC it would be really bad.

And hypothetical systems with 100*TSC justify all that?

> There were systems in the past that ran TSC at a much slower frequency,
> such as the early AMD Barcelona systems.
>
> So the problem may eventually come back if not solved properly.

There are better ways to do that than using heuristics. We have to
deal with 3 variants of the reference counter:

1) Core and Atom: counts bus cycles and we know that frequency already
from the local apic calibration

2) Nehalem, Westmere: Same as TSC

3) Sandybridge and later: XCLK which is 100MHz

No magic calibration, just use the information which we have on our
hands already.

Thanks,

tglx


\
 
 \ /
  Last update: 2015-04-24 11:21    [W:0.093 / U:0.564 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site