Re: [ANNOUNCE] ktimers subsystem

[john stultz <johnstul@us.ibm.com>]

On Tue, 2005-09-20 at 00:44 +0200, Thomas Gleixner wrote:
> On Mon, 2005-09-19 at 15:24 -0700, Christoph Lameter wrote:
> 
> > > We should rather ask glibc people why gettimeofday() / clock_getttime()
> > > is called inside the library code all over the place for non obvious
> > > reasons.
> > 
> > You can ask lots of application vendors the same question because its all 
> > over lots of user space code. The fact is that gettimeofday() / 
> > clock_gettime() efficiency is very critical to the performance of many 
> > applications on Linux. That is why the addtion of one add instruction may 
> > better be carefully considered. 
> 
> Hmm. I don't understand the argument line completely. 
> 
> 1. The kernel has to provide ugly mechanisms because a lot of
> applications implementations are doing the Wrong Thing ?
> 
> 2. All gettimeofday implementations I have looked at do a lot of math
> anyway, so its definitely more interesting to look at those oddities
> rather than discussing a single add. John Stulz timeofday rework have a
> clean solution for this - please do not argue about the div64 in his
> original patches which he is reworking at the moment.

The simplest solution is to keep wall-time maintained in a timespec as
well as the nsec_t based system_time/wall_time_offset combo. This avoids
the extra add in the hotpath, and only costs an extra add at interrupt
time.

I'll have an updated patch that includes some of Roman's suggestions
from earlier soon.

> > Many platforms can execute gettimeofday 
> > without having to enter the kernel.
> 
> Which ones ? How is this achieved with respect to all the time adjust,
> correction... code ?

Many arches have userspace gtod implementations (x86-64, ppc64, and ia64
as well). Although my timeofday code allows for this as well (I had it
working for x86-64 awhile back). 

thanks
-john