On Mon, Dec 06, 2010 at 03:27:18PM +0200, Avi Kivity wrote: > >A vcpu could be idle not just because of lack of work, but also because its > >waiting on IO completion. Normally idle vcpus that yield would allow their > >companion threads to run and possibly finish pending IO work faster. Now that > >idle vcpu won't yield, it would cause overall cpu cycle demand of VMs to go up > >(100% demand from VM's idle/not-idle vcpus + whatever their companion threads > >demand) not to mention any impact on IO latencies. Not sure how much of an issue > >this will be in practice, but something to keep in mind when we test! > > It will be an issue. Anything that is latency sensitive will > suffer, since the scheduler won't prioritize completions (at least > in vcpu threads). But that only affects the average case, not the > worst case. Yeah - some testing will tell us how much of an issue this is for various workloads. > >Also, just curious how this would work for idle vcpus that use mwait rather > >than hlt. > > We don't expose mwait to the guest (emulating mwait is very expensive). We seem to be queuing an exception upon mwait (EXIT_REASON_MWAIT_INSTRUCTION being handled by a handle_invalid_op()). Does that kill the guest? - vatsa -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
