Aurelien Jarno wrote: > >> What is your disk image file format, or are you using a partition? >> > > I am using a raw image file on an ext3 partition. > > >> Do the results change (on kvm-14) if you pin the guest to a core with >> 'taskset 1 qemu ...' >> > > Bingo. It now works even faster than kvm-13! > > real 0m22.307s > user 0m13.935s > sys 0m4.720 > >
I'm guessing this is due to the glibc aio implementation, which uses threads instead of true aio. The threads may cause the vcpu to migrate frequently from one code to another. There are two possible solutions: - use native aio from http://www.bullopensource.org/posix/. I think the aio signal patches are not yet in, so this may not work. - teach the scheduler about the cost of migrating vcpus The first approach will solve itself eventually, though slowly if the current slow rate of aio merging continues. We'll have to do the second. > >> Thank you for taking the time to do real measurements and report the >> results clearly. That makes it possible (I hope) to find the cause and >> fix it. >> > > Thanks for your help! Do you think this problem is fixable? On my final > machine, I have a dozen of qemu/kvm running, and when I start them I > don't know how they will be used, and so how to pin them on the two cores. > For a temporary solution, I'd just pick a random core in a startup script and trust to probability. Hopefully the scheduler will get fixed to handle vcpus soon. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ kvm-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/kvm-devel
