On Tue, 26 Feb 2002, george anzinger wrote:
> Tim Schmielau wrote:
> >
> > This is a polished version of the patch that came out of the
> > "[Patch] Re: Nasty suprise with uptime" thread last november.
> >
[...]
> > Before submitting the patch to Marcelo for 2.4.19-pre, I'd like to get
> > some comments, especially on the following points:
> >
> > 1. Does the patch, in particular the introduction of get_jiffies64(),
> > interfere with the high-res-timers project
> > (http://sourceforge.net/projects/high-res-timers) in any bad way?
>
> Well, since you asked (thank you), the high-res-timers patch needs to
> get the full 64-bit uptime to implement CLOCK_MONOTONIC. Also, since
> the timers in the kernel are, in fact clocked by CLOCK_MONOTONIC (read
> jiffies) the code has to resolve any wall clock time (i.e.
> CLOCK_REALTIME) into CLOCK_MONOTONIC as part of the timer_settimer()
> call. This means that the 64-bit jiffies is used "often" in this code.
> In discussions on the list with Linus, he suggested that the jiffies
> counter be expanded to 64-bits in a particular way, i.e. by #define
> jiffie ... taking into account the endian and 64/32 bitness of the
> particular platform. I think this is what I implemented in the
> high-res-timers patch. This implementation allows almost all users to
> continue to work with 32-bit jiffies while providing a 64-bit value for
> those who need it. Unlike this patch, it keeps the 64-bit rational
> (i.e. always current) by doing a 64-bit add which adds an "adc" (add
> carry to memory) to the timer interrupt path. This update is already
> SMP protected so no additional locking is required on update. Reading
> it CAN be done with out locking if it is done with care (read high, low,
> high, if high1 != high2 do it again) or a read lock can be taken.
>
> The only down side I see to the suggested 64-bit jiffies as implemented
> in the high-res-timers patch is the name space collision issue around
> the #define of jiffies. I think I have found almost all of these,
> however, it is hard to come up with a .config that compiles ALL paths
> (especially considering the various archs).
Well, my intention was not to push this patch into high-res-timers.
Rather, once this patch may have made it into the kernel, the
high-res-timers patch should back out the simple 64 bit jiffies stuff,
i.e. init_jiffieswrap_timer(), check_jiffieswrap() and get_jiffies64(),
and do all this in its own way, just provide a new get_jiffies64()
function that does the (read high, low, high; compare) stuff.
If you see problems with the get_jiffies64() interface, or prefer another
name, please say so.
Since you did not raise any hard objections, I count this as an "you moron
put some extra work on me, but I can stand it, so it's OK with me" ;-)
Thanks,
Tim
-
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/
This archive was generated by hypermail 2b29 : Thu Feb 28 2002 - 21:00:32 EST