Re: [PATCH/RFC 10/10] example of simple continuous gettimeofday

[Ingo Molnar <mingo@elte.hu>]

* john stultz <johnstul@us.ibm.com> wrote:

> > - I still don't like the idea of a generic gettimeofday() as it prevents
> >   more optimized versions, e.g. on the one end with a 1MHz clock you only
> >   have usec resolution anyway and this allows to keep almost everything
> >   within 32bits. On the other end 64bit archs can avoid the "if (nsec >
> >   NSEC_PER_SEC)" by doing something like ppc64 does, but requires a
> >   different scaling of the values (to sec instead of nsec).
> 
> Fair enough. I agree arches should be able to have their own arch 
> specific implementations. If you really have to micro-optimize 
> everything, just don't enable CONFIG_GENERIC_TIME and have your own 
> timekeeping subsystem!
> 
> But at the same time, I don't like the idea of needlessly having 26 
> different versions of gettimeofday that do exactly the same thing 
> modulo a few bugs. :)

I like the first 9 patches, but regarding 10/10 i very much agree with 
John: it moves us to per-arch gettimeofday again, which is a big step 
backwards and reverts some of the biggest advantage of John's 
clocksource patchset!

Also, lets face it: with the union ktime_t type most of the '64-bit is 
slow on 32-bit' issues are much less of a problem. If some 32-bit arch 
wants to pull off its own timekeeping system, it can do so - but 
otherwise we want to move towards generic, unified (as far as it makes 
sense) and generally 64-bit-optimized subsystems. In 1995 i'd have 
agreed with Roman, but not in 2005.

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