Re: [RFC] [PATCH] fix gettimeofday() on parisc to be monotonic

On 12/20/06, Helge Deller <[email protected]> wrote:
> I would like to get your feedback on the attached patch.
>
> While testing the Linux Test Project gettimeofday02 testcase, I found that our gettimeofday() implementation is not monotonic.
> I know there was much work on gettimeofday() a few monthes back, but still we have problems.
> Just try this stripped-down testcase yourself:
> The patch below fixes this nicely for PARISC-Linux, while it removes our own implementation and uses the existing CONFIG_TIME_INTERPOLATION framework.
> AFAICS up to now it's only used by IA64 and SPARC64.

I think this idea is great! I haven't reviewed the patch, but I think
it's a great idea. I was looking at this stuff during OLS when the new
timing framework was presented.

> The things where I wanted to get your feedback on is, that on a 32bit HPPA Kernel we don't allow cmpxchg() with a 8-byte variable, which is used in the generic code in kernel/timer.c line 1674.
> To make my implementation work, I changed some "u64" variables/struct members in the "struct time_interpolator" in include/linux/timex.h  to "cycles_t" instead.
> "cycles_t" is defined in include/asm/timex.h mostly as "unsigned long", which is what the default platform width is (e.g. 64bit on 64bit platforms) and get_cycles() is exactly the input-value for the time interpolation framework.
> As such I think it just makes sense to use this type as well all over the code.
> For PARISC this chage gives 8bytes on HPPA64 and 4bytes on HPPA32, and so we can use the current implementation with the cmpxchg() in kernel/timer.c.

This sounds like a good idea. The use of u64 is probably because only
IA64 and SPARC64 have been using this code.

Each arch doing their own accounting of time seems silly. I think this
generic infrastructure is just what we need. I'm glad to see that
gettimofday is going to get better.

A broken timer can cause all sorts of problems in userspace.

Thanks Helge!

c.