>Paul Brook wrote: >> > Yes, good thinking, but this should only be done if it actually >impacts >> > something. Reducing overhead from 0.1% to 0.05% is not worthwhile >if it >> > introduces extra complexity. >> >> If the overhead is that small, why are we touching this code in the >first >> place? > >Insightful. > >A benchmark result was posted which is rather interesting: > >>[EMAIL PROTECTED] ~]$ time ./hackbench 50 >>x86_64 host : real 0m10.845s >>x86_64 host, bound to 1 cpu : real 0m21.884s >>i386 guest+unix clock : real 0m49.206s >>i386 guest+hpet clock : real 0m48.292s >>i386 guest+dynticks clock : real 0m28.835s >> >>Results are repeatable and verfied with a stopwatch because I didn't >>believe them at first :) > >I am surprised if 1000 redundant SIGALRMs per second is really causing >70% overhead in normal qemu execution, except on a rather old or slow >machine where signal delivery is very slow. > >It would be good to understand the cause of that benchmark result.
while I don't know the benchmark [I head it's something like paralled chat messaging, the performance gain is probably achieved by improved latency and response times that the dyn-tick provides. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
