Re: boot time, process start time, and NOW time

[Tim Schmielau]

(Whoops, this generated quite some traffic while I was asleep.
I'll just comment on some of the posts in a single mail.)

On Mon, 16 Aug 2004, George Anzinger wrote:

> > George is absolutely right that it's more precise. However, it's also
> > inconsistent with the process start times which use plain uncorrected
> > jiffies. ps stumbles over this inconsistency.
> >
> > Simple fix: revert the patch below.
> > Complicated fix: correct process start times in fork.c (no patch 
provided,
> > too complicated for me to do).
> >
> > George?
>
> Hm...  That patch was for a reason...  It seems to me that doing 
anything shor
t
> of putting "xtime" (or better, clock_gettime() :)) in at fork time is 
not goin
g
> to fix anything.

Yep. I think that's the way to go.

>                   As written the start_time in the task_struct is fixed.  
If
> "now - uptime + time_from_boot_to_process_start" it is wandering, it 
must be t
he
> fault of "now - uptime".  Since this seems to be wandering, and we 
corrected
> uptime in the referenced patch, is it safe to assume that "now" is 
actually
> being computed from "jiffies" rather than a gettimeofday()?

No, it's not "now" which is wandering, but the difference between "uptime"
and "time_from_boot_to_process_start". The former gets corrected by ntp,
while the latter is computed from "jiffies" and thus uncorrected.



On Mon, 16 Aug 2004, john stultz wrote:

> Hmm. While that patch fixed the uptime proc entry, I thought the issue
> was with process start times. I'm looking at fixing the start_time
> assignment in proc_pid_stat(). My suspicion is that we need to use ACTHZ
> in jiffies64_to_clock_t().

No, we already fixed jiffies64_to_clock_t() by using TICK_NSEC instead of
HZ.



On Mon, 16 Aug 2004, George Anzinger wrote:

> I really don't see how the start_time that proc_pid_stat() is producing 
could be
> anything but a constant.  The complaint is that it moves, not that it is
> incorrect, right?

No, proc_pid_stat() indeed gives a constant. But userspace somehow has to
figure out what a value in "jiffies" means. Since "jiffies" started from 
zero
at boot time, "uptime" is needed for that. However, we "fixed" uptime to
get corrected by ntp, so that userspace now has a drifting notion of 
"jiffies".



On Tue, 16 Aug 2004, Albert Cahalan wrote:

> If you're interested in reducing (not solving)
> the problem for the 2.6.x series, you might change
> HZ to something that works better with the PIT.

No, that's not needed anymore. We've already started to account for the
difference, e.g. by using TICK_NSEC in jiffies64_to_clock_t().

Problem is, we are only halfway through the attempt to remove the use
of "jiffies" as a clock, so currently to incompatible time sources get 
mixed
up.

The other problem seems to be that this move away from "jiffies" seems to
happen on an ad-hoc basis whenever we encounter a problem, rather than
with a big picture in mind.
John Stultz once laid out a concept for a (coordinated) rewrite in 2.7,
and I think this still is a good idea.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/