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. -- Jamie ------------------------------------------------------------------------- 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
