Re: [ANNOUNCE] kvm-14 release

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

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