Re: performance trouble

[Peter Lieven <pl@dlh.net>]

On 22.03.2012 09:31, David Cure wrote:
> Le Wed, Mar 21, 2012 at 06:31:02PM +0100, Peter Lieven ecrivait :
>> please keep in mind, that setting -hypervisor, disabling hpet and only
>> one vcpu
>> makes windows use tsc as clocksource. you have to make sure, that your vm
>> is not switching between physical sockets on your system and that you have
>> constant_tsc feature to have a stable tsc between the cores in the
>> same socket. its also likely that the vm will crash when live migrated.
> 	ok, yet I "only" have disable hpet and use 1vcpu.
you have to use 1 vcpu on 32-bit windows. 64-bit seems to
work with more than 1 vcpu. why all those limitations:
windows avoids using tsc in a hypervisor which is a good decision.
problem is it falls back to pm_timer or hpet. both of them are very
expensive in emulation currently because kvm exits kernel mode
and the userspace qemu-kvm handles this. i have done experiments
where i saw ~20.000 userpace exits just for pmtimer reads. this
made up ~30-40% of the whole processing power. every call to a
QPC timer in windows causes a pm_timer/hpet read. especially
each i/o request seems to cause a QPC timer read and which
is odd as well a lazy fpu call (but this is a differnt issue) which also
is very expensive to emulate (currently).

> 	for the switching I need to pin the vcpu on 1 physical proc,
> right ?
you need 1 vcpu for 32-bit windows and disabling hypervisor to
cheat windows and make it think it runs on real hardware. it then
uses tsc.
> 	for constant_tsc, how can I check if I use it ?
cat /proc/cpuinfo on the host. there should be a flag 'constant_tsc'.
it might be that also rdtscp is necessary.
> 	for live migration : what is the "feature" that cause trouble :
> -hypervisor, hpet, vcpu or all ?
using tsc as clocksource is the problem not the features themselves.

peter
> 	David.
>