tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Bug fix for PR 26470 for review

On 25 May 2008, at 18:58 , Joerg Sonnenberger wrote:

On Sun, May 25, 2008 at 06:32:35PM -0700, Dennis Ferguson wrote:
That patch is much better.

On 11 Jan 2009, at 22:38 , Joerg Sonnenberger wrote:
Well, setitimer is supposed to change with the real time and I would
argue that settimeofday modifies the real time.

I think you are confusing real time with real time intervals. The two are different enough that timekeeping conferences mention them as separate
topics, e.g.

I'm quoting the wording of SUS of setitimer(2) here.

Well, if we're reduced to quoting standardese, how about this one
from the SUS for clock_settime():

    Setting the value of the CLOCK_REALTIME clock via clock_settime()
    shall have no effect on threads that are blocked waiting for a
    relative time service based upon this clock, including the
nanosleep() function; nor on the expiration of relative timers based upon this clock. Consequently, these time services shall expire when the requested relative interval elapses, independently of the new or
    old value of the clock.

The "relative timers based upon this clock" it is talking about that shouldn't be effected by clock_settime() include the one managed via setitimer(). This
directly contradicts what you asserted above.

I've attached a program which exercises this. Notice the interval between "alarm 4" and "alarm 5" is very different when a call to clock_settime() is made compared to when it isn't. That's the behaviour the standard disallows.

If you want a timescale where the difference between
two timestamps reliably reflects the interval between them you can't use a timescale which is subject to phase adjustments, which is why the kernel
uptime works here while kernel time is a bit broken.

The problem with using uptime is that it won't help for stepping in the
time as done e.g. by settimeofday. This matches the description of
clock_gettime. The uptime behavior would match the non-existing
ITIMER_MONOTONIC. That doesn't make a difference during normal
operation, but as soon as e.g. the system can be suspended for arbitrary
intervals, it becomes quite obvious.

I don't know what behaviour you are talking about.  time and uptime
are (or should be) the same time from the same clock; they differ only by
a near-constant "boottime" which is maintained so that

    time = uptime + boottime

Essentially boottime and uptime are the separated phase and frequency
components of CLOCK_REALTIME time.  boottime is only changed by calls
to clock_settime(), settimeofday() and the equivalent operation at the
NTP system call interface.  Otherwise time and uptime are entirely
synchronous and advance at the same rate. They are the same clock.  So,
when the standard says you need to use a time which is CLOCK_REALTIME,
but which is unaffected by calls to clock_settime(), they are talking
precisely about uptime because that is what uptime is.

I don't have a good handle on what timers should do when the system isn't
running (nor does the SUS, for that matter), so if you don't like what
uptime does when the system is suspended feel free to fix that (maybe
you can set uptime = time - boottime when you wake up).  I can tell you
for sure, however, that what uptime does when the system is running is
exactly, precisely what relative time functions need (if it isn't it
should be fixed).  That is its purpose, its only purpose.

Note that this is a very small problem in most cases since, as you point
out, most people don't use settimeofday() very often. What is mystifying
me, however, is that while someone went to a great deal of trouble to
add the infrastructure to your kernel to entirely eliminate this small
problem (and many others like it, actually), you are declining to use
it for precisely the thing it was meant to be used for.  What was the
point of adding it?

Given the guarantied reslution of 1/HZ only the effect of phase
adjustments should be irrelevant.

Umm, we're not talking small differences here. Try the attached program.

Dennis Ferguson

Attachment: r.c
Description: Binary data

Home | Main Index | Thread Index | Old Index