David Xu wrote: > David Xu wrote: > >> Poul-Henning Kamp wrote: >> >>> In message <4361F057.4030904_at_pp.nic.fi>, Pertti Kosunen writes: >>> >>> >>>> Does polling affect to this test? >>> >>> >>> >>> >>> Not apart from the CPU overhead. >>> >>> sysctl kern.timecounter.hardware >>> >>> is much more important. >>> >>> and all the reports here which fail to include it are mostly >>> useless. >>> >>> >> I suspect because our time() function in libc uses gettimeofday, >> this further causes lots of gettimeofday syscall. >> >> > Now, I can confirm mysqld calls time() function lots of time, I have > changed time() to call clock_gettime, now there is few of gettimeofday > in ktrace result, but fully filled by clock_gettime. > Can we optimize time()? because it only returns second. > may we just create a syscall to return time_second variable in kernel, > this sounds crazy though. > Hey guys, I been watching this thread and I can confirm that MySQL and the Super-smack benchmark greatly rely on this, I was able to increase performance %600 by changing kern.timecounter.hardware to dummy. kessel# sysctl kern.timecounter.hardware=dummy kern.timecounter.hardware: ACPI-fast -> dummy kessel# super-smack /usr/share/smacks/select-key.smack 10 10000 Query Barrel Report for client smacker1 connect: max=0ms min=0ms avg= 0ms from 10 clients Query_type num_queries max_time min_time q_per_s select_index 200000 0 0 151328.05 kessel# sysctl kern.timecounter.hardware=TSC kern.timecounter.hardware: dummy -> TSC kessel# super-smack /usr/share/smacks/select-key.smack 10 10000 Query Barrel Report for client smacker1 connect: max=3ms min=2ms avg= 2ms from 10 clients Query_type num_queries max_time min_time q_per_s select_index 200000 0 0 25739.90 kessel# sysctl kern.timecounter.hardware=ACPI-fast kern.timecounter.hardware: TSC -> ACPI-fast kessel# super-smack /usr/share/smacks/select-key.smack 10 10000 Query Barrel Report for client smacker1 connect: max=3ms min=2ms avg= 2ms from 10 clients Query_type num_queries max_time min_time q_per_s select_index 200000 0 0 24070.67Received on Fri Oct 28 2005 - 10:33:17 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:46 UTC