lkml.org 
[lkml]   [2004]   [Oct]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: process start time set wrongly at boot for kernel 2.6.9
From
Date
On Wed, 2004-10-20 at 16:52, George Anzinger wrote:
> john stultz wrote:
> > On Wed, 2004-10-20 at 07:51, George Anzinger wrote:
> >
> >>john stultz wrote:
> >>
> >>>I've begun to agree with you about this issue. It seems that until we
> >>>can catch every use of jiffies for time, doing one by one is going to
> >>>cause consistency problems. So I'd support the full backout of the
> >>>do_posix_clock_monotonic_gettime changes to the proc interface.
> >>>
> >>>George, would you protest this?
> >>
> >>It seems to me that if we do that we will stop making any changes at all. I.e.
> >>we will not see the rest of the "jiffies for time" code, as it will not "hurt"
> >>any more.
> >
> >
> > Sorry, not sure I followed that. Could you explain further?
>
> If we rip out the code folks will stop sending in bug reports on it. Simple as
> that.

So you feel that we're moving in the right direction, its just that its
going to take a few passes before everything smooths out? Thus its just
a continuation of the effort?

Tim? Is this OK with you, or you feel the immediate inconsistencies and
bug reports aren't worth the effort?


> > So rather then every tick incrementing jiffies, instead jiffies is set
> > equal to (monotonic_clock()*HZ)/NSEC_PER_SEC.
>
> As mention by me (a long time ago), this assumes you have a better source for
> the clock than the interrupt. I would argue that on the x86 (which I admit is
> really deficient) the best long term clock is, in fact, the PIT interrupt. The
> _best_ clock on the x86, IMHO, is one that used the PIT interrupt as the gold
> standard. Then one smooths this to eliminate interrupt latency issues and lost
> ticks using the TSC. The pm_timer is as good as the PIT but suffers from
> access time issues.

Well, assuming the PIT is programmed to a value it can actually run at
accurately, you might be right.

The only problem is I've started to arrive at the notion of
interpolation between multiple problematic timesources is just a rats
nest. When you can't trust timer interrupts to arrive and you can't
trust the TSC to run at the right frequency, there's no way to figure
out who's right. We already have the lost-tick compensation code, but
we still get time inconsistencies. Now maybe I'm just too dim witted to
make it work, but the more I look at it, the more corner cases appear
and the uglier the code gets.

I say pick a timesource you can trust on your machine and stick to it.
NTP is there to correct for drift, so just use it.

-john



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:07    [W:0.163 / U:0.924 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site