Prev: Protect prefetch macro arguments.
Next: dmar: section mismatch cleanup
From: john stultz on 28 Mar 2010 21:10
On Fri, 2010-03-26 at 14:46 -0700, Joel Becker wrote:
> On Tue, Mar 23, 2010 at 11:36:11PM -0400, Yury Polyanskiy wrote:
> > Second, and more importantly, loops_per_jiffy has little to do with the conversion from the
> > the time scale of get_cycles() (aka rdtsc) to the time scale of jiffies.
>
> It used to! Fundamentally, of course, we didn't have a
> monotonic clock everywhere that satisfied hangcheck-timer's needs. So
> we had to use different approaches on different architectures.
>
> > @@ -130,7 +129,9 @@ extern unsigned long long monotonic_clock(void);
> > #else
> > static inline unsigned long long monotonic_clock(void)
> > {
> > - return get_cycles();
> > + struct timespec ts;
> > + getrawmonotonic(&ts);
> > + return timespec_to_ns(&ts);
> > }
> > #endif /* HAVE_MONOTONIC */
>
> I have two questions:
>
> 1) Does getrawmonotonic() satisfy hangcheck-timer? What I mean is, will
> it always return the wallclock nanoseconds even in the face of CPU speed
> changes, suspend, udelay, or any other suspension of kernel operation?
> Yes, I know this is a tougher standard than rdtsc(), but this is what
> hangcheck-timer wants. rdtsc() at least satisfied udelay and PCI hangs.

getrawmonotonic() can be stalled and will wrap on some hardware (acpi pm
timer wraps every 5 seconds).

I think the read_persistent_clock() is really what you want to use here.
On arches that do not support it, it returns 0 every time.

thanks
-john



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Yury Polyanskiy on 29 Mar 2010 10:20
On Sun, 28 Mar 2010 18:00:36 -0700
john stultz <johnstul(a)us.ibm.com> wrote:

> > 1) Does getrawmonotonic() satisfy hangcheck-timer? What I mean is, will
> > it always return the wallclock nanoseconds even in the face of CPU speed
> > changes, suspend, udelay, or any other suspension of kernel operation?
> > Yes, I know this is a tougher standard than rdtsc(), but this is what
> > hangcheck-timer wants. rdtsc() at least satisfied udelay and PCI hangs.
>
> getrawmonotonic() can be stalled and will wrap on some hardware (acpi pm
> timer wraps every 5 seconds).
>

I am not sure which archs do you mean. But in any case,
getrawmonotonic() is not just a wrap around a call to rdtsc() (or acpi
pm timer read). It is based on the clock->raw_time, which is updated
every timer interrupt by the update_wall_time(). So even if underlying
timer wraps, it doesn't lead to getrawmonotonic() returning 0 sec.


Y
From: john stultz on 29 Mar 2010 12:50
On Mon, 2010-03-29 at 10:11 -0400, Yury Polyanskiy wrote:
> On Sun, 28 Mar 2010 18:00:36 -0700
> john stultz <johnstul(a)us.ibm.com> wrote:
>
> > > 1) Does getrawmonotonic() satisfy hangcheck-timer? What I mean is, will
> > > it always return the wallclock nanoseconds even in the face of CPU speed
> > > changes, suspend, udelay, or any other suspension of kernel operation?
> > > Yes, I know this is a tougher standard than rdtsc(), but this is what
> > > hangcheck-timer wants. rdtsc() at least satisfied udelay and PCI hangs.
> >
> > getrawmonotonic() can be stalled and will wrap on some hardware (acpi pm
> > timer wraps every 5 seconds).
> >
>
> I am not sure which archs do you mean. But in any case,
> getrawmonotonic() is not just a wrap around a call to rdtsc() (or acpi
> pm timer read). It is based on the clock->raw_time, which is updated
> every timer interrupt by the update_wall_time(). So even if underlying
> timer wraps, it doesn't lead to getrawmonotonic() returning 0 sec.

What I'm saying is that if you're using getrawmonotonic() to detect
hangs, you might miss them, as getrawmonotonic may wrap (and thus stop
continually increasing) if the timer interrupt is delayed. This does not
apply to systems using the TSC clocksource, but does apply to systems
using the acpi_pm.

read_persistent_clock() is likely a better interface to use, because it
returns the seconds usually from the CMOS clock which runs continually
without any OS maintenance.

The only complication there would likely be hwclock syncing (either by
hand or via NTP), but that could be handled by a
touch_hangcheck_watchdog() style notifier.

thanks
-john


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Yury Polyanskiy on 29 Mar 2010 13:10
On Mon, 29 Mar 2010 09:43:27 -0700
john stultz <johnstul(a)us.ibm.com> wrote:

> > I am not sure which archs do you mean. But in any case,
> > getrawmonotonic() is not just a wrap around a call to rdtsc() (or acpi
> > pm timer read). It is based on the clock->raw_time, which is updated
> > every timer interrupt by the update_wall_time(). So even if underlying
> > timer wraps, it doesn't lead to getrawmonotonic() returning 0 sec.
>
> What I'm saying is that if you're using getrawmonotonic() to detect
> hangs, you might miss them, as getrawmonotonic may wrap (and thus stop
> continually increasing) if the timer interrupt is delayed. This does not
> apply to systems using the TSC clocksource, but does apply to systems
> using the acpi_pm.

But if timer interrupt is delayed by more than acpi_pm wrap-around
time, then the update_wall_time() is also screwed. Since it is not, we
can rely on getrawmonotonic().

Y
From: john stultz on 29 Mar 2010 14:50
On Mon, 2010-03-29 at 13:04 -0400, Yury Polyanskiy wrote:
> On Mon, 29 Mar 2010 09:43:27 -0700
> john stultz <johnstul(a)us.ibm.com> wrote:
>
> > > I am not sure which archs do you mean. But in any case,
> > > getrawmonotonic() is not just a wrap around a call to rdtsc() (or acpi
> > > pm timer read). It is based on the clock->raw_time, which is updated
> > > every timer interrupt by the update_wall_time(). So even if underlying
> > > timer wraps, it doesn't lead to getrawmonotonic() returning 0 sec.
> >
> > What I'm saying is that if you're using getrawmonotonic() to detect
> > hangs, you might miss them, as getrawmonotonic may wrap (and thus stop
> > continually increasing) if the timer interrupt is delayed. This does not
> > apply to systems using the TSC clocksource, but does apply to systems
> > using the acpi_pm.
>
> But if timer interrupt is delayed by more than acpi_pm wrap-around
> time, then the update_wall_time() is also screwed. Since it is not, we
> can rely on getrawmonotonic().

Right, if the box hangs for longer then the clocksource can count for,
the timekeeping subsystem will be off by some multiple of that length.

And That's exactly why I'm advising against using
gettimeofday/getrawmonotonic or any other software managed sense of time
for the hangcheck timer, as you won't be able to correctly detect hangs.

I'm also suggesting using something like read_persistent_clock() is
better, because there is no OS/software management involved (other then
the minor syncing issue I mentioned before) so if the system hangs for a
long period of time, then returns, you'll still be able to detect the
hang.

But maybe what folks are using the hangcheck timer for is shifting, so
its possible that I'm not quite understanding what you're trying to do
here.

thanks
-john

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Protect prefetch macro arguments.
Next: dmar: section mismatch cleanup