[lkml]   [2007]   [Feb]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [-mm patch] x86_64 GTOD: offer scalable vgettimeofday II

    * Andi Kleen <> wrote:

    > > The 'price' paid for it is lower resolution - but it's still good
    > > for those benchmarking TPC-C runs - and /alot/ simpler.
    > BTW another comment: I was told that at least one of the big databases
    > wants ms resolution here. So to make your scheme work would require a
    > HZ=1024 regular interrupt. [...]

    if resolution is an issue then i can improve this thing to be based off
    a separate /optional/ hrtimer, thus if it's enabled it could enable 1000
    Hz (and not 1024 Hz) update for the variable. The update resolution
    could be tuned via a sysctl trivially, so everyone could tune the
    resolution of this to the value desired, and could do so runtime.

    [ It could also be driven by the database right now: from a thread open
    /dev/rtc, set it to 1024 HZ, and do a gettimeofday() call in every
    tick - that will auto-update the timestamp. ]

    > [...] But that would also make everything slower again due to CPU
    > overhead as it was learned in the 2.4->2.6 HZ transition.

    note that this cost was measured on UP and on older hardware, and the
    cost of having a global 1000 Hz update gets linearly cheaper with the
    increase of CPUs on SMP: because only one such update has to be running.
    The systems those database vendors are interested in typically have a
    fair number of CPUs.

    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: 2007-02-01 13:29    [W:0.295 / U:47.128 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site