[lkml]   [2004]   [Aug]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: boot time, process start time, and NOW time
(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
> > too complicated for me to do).
> >
> > George?
> Hm... That patch was for a reason... It seems to me that doing
anything shor
> of putting "xtime" (or better, clock_gettime() :)) in at fork time is
not goin
> to fix anything.

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

> As written the start_time in the task_struct is fixed.
> "now - uptime + time_from_boot_to_process_start" it is wandering, it
must be t
> fault of "now - uptime". Since this seems to be wandering, and we
> uptime in the referenced patch, is it safe to assume that "now" is
> 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

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
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

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

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
More majordomo info at
Please read the FAQ at

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