[lkml]   [2005]   [Sep]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [ANNOUNCE] ktimers subsystem

    * 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. 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. ]

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-09-20 11:38    [W:0.022 / U:0.048 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site