* Andi Kleen <[EMAIL PROTECTED]> 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.
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/
