* Christoph Lameter <[email protected]> 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. Many platforms can execute
> gettimeofday without having to enter the kernel.
i think this line of argument got into a bit of a wrong direction: do we
seriously consider a single 'add' as an argument to _not_ go to a much
cleaner implementation? The answer is very simple: we dont. In the core
kernel we frequently skip other, much worthier micro-optimizations in
favor of cleanliness. The time subsystem has been limping along for
many, many years, and to bring new life into it we need John's and
Thomas's stuff. Simple as that. I'd give up much more than just a single
cycle add overhead for that ...
it's probably not even worth keeping the timespec 'cached' in parallel
to nsec_t - but in any case, speedups like that should be considered
totally separately - cleanliness, the main problem of the whole time
subsystem, comes first. _Once_ cleanliness has been achieved, we can
consider micro-optimizations anew, and judge them by how much they bring
and how they affect cleanliness.
[ Even when not considering cleanliness at all, the best opportunities
for optimizations are elsewhere. E.g. we could speed up
sys_gettimeofday() much more by skipping a number of hardware bug
workarounds that affect the quality of e.g. the TSC, and other timer
hardware details that are simpler on modern hardware. So if someone is
after sys_gettimeofday() performance, dont look for a single add (or
even a single division), go for the bigger picture first. E.g. the
vsyscall people went for the bigger picture on modern platforms and
sped sys_time up by doing it in userspace most of the time and thus
skipping hundreds of cycles of syscall entry overhead - not a cycle
like an add is. ]
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |