lkml.org 
[lkml]   [2005]   [Sep]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [ANNOUNCE] ktimers subsystem
From
Date
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.

> 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 ?

tglx


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

\
 
 \ /
  Last update: 2005-09-20 00:47    [W:0.140 / U:0.280 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site