Re: [ANNOUNCE] ktimers subsystem

[Ingo Molnar <mingo@elte.hu>]

* Christoph Lameter <clameter@engr.sgi.com> 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 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/