From: Joel Becker <Joel.Becker@oracle.com>
To: john stultz <johnstul@us.ibm.com>
Cc: lkml <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH][2.5] hangcheck-timer
Date: Mon, 20 Jan 2003 18:00:16 -0800 [thread overview]
Message-ID: <20030121020015.GQ20972@ca-server1.us.oracle.com> (raw)
In-Reply-To: <1043113336.32478.97.camel@w-jstultz2.beaverton.ibm.com>
On Mon, Jan 20, 2003 at 05:42:16PM -0800, john stultz wrote:
> get_cycles() is a poor method for determining "real time".
> Please use do_gettimeofday().
Does do_gettimeofday() exist on all platforms? Does it indeed
give actual wall clock time, instead of the inaccurate time jiffies can
give?
> I believe you mean "udelay for 60 micro-seconds"
No, I mean 60 *seconds*. There have been drivers and such that
do pause the entire box that long.
> Wait, so 180 seconds is the margin of error?
Yup, for the default. I'm not beholden to these specific
defaults. They're just the defaults we use in our environment.
> > + if (tsc_diff > hangcheck_tsc_margin) {
>
> but now we're using it to compare cycles! 180sec != 180 cycles
Look at the calculations. I'm comparing cycles to cycles,
calculated from the original seconds.
> Additionally, this code doesn't take systems that have unsync'ed TSCs,
> or systems that change cpu frequency into account. Again, please use
> do_gettimeofday(). Then you can then talk about the values returned in
> secs and usecs, and I believe things will be much more clear.
I'll look into it, but it must absolutely be in terms of wall
clock time as measured from outside the system.
Joel
--
Life's Little Instruction Book #99
"Think big thoughts, but relish small pleasures."
Joel Becker
Senior Member of Technical Staff
Oracle Corporation
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127
next prev parent reply other threads:[~2003-01-21 1:51 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200301210135.h0L1ZFa06867@eng2.beaverton.ibm.com>
2003-01-21 1:42 ` [PATCH][2.5] hangcheck-timer john stultz
2003-01-21 2:00 ` Joel Becker [this message]
2003-01-21 2:45 ` john stultz
2003-01-21 17:29 ` Joel Becker
2003-01-21 20:03 ` john stultz
2003-01-21 20:30 ` Joel Becker
2003-01-21 1:19 Joel Becker
2003-01-21 8:11 ` Christoph Hellwig
2003-01-21 17:33 ` Joel Becker
2003-01-21 12:50 ` Dave Jones
2003-01-21 17:40 ` Joel Becker
2003-01-21 17:42 ` Dave Jones
2003-01-21 18:42 ` Joel Becker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030121020015.GQ20972@ca-server1.us.oracle.com \
--to=joel.becker@oracle.com \
--cc=johnstul@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.