Re: [PATCH] kvm-vmx: add module parameter to avoid trapping HLT instructions (v4)
On 12/06/2010 03:39 PM, Srivatsa Vaddagiri wrote: > >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? It sends a #UD, which tells the guest mwait isn't supported. Usually the guest will fall on its sword at this point, but that's not mandated. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] kvm-vmx: add module parameter to avoid trapping HLT instructions (v4)
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] kvm-vmx: add module parameter to avoid trapping HLT instructions (v4)
On 12/05/2010 06:55 PM, Srivatsa Vaddagiri wrote: On Sat, Dec 04, 2010 at 08:43:21AM -0600, Anthony Liguori wrote: > In certain use-cases, we want to allocate guests fixed time slices where idle > guest cycles leave the machine idling. There are many approaches to achieve > this but the most direct is to simply avoid trapping the HLT instruction which > lets the guest directly execute the instruction putting the processor to sleep. 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. 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). -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] kvm-vmx: add module parameter to avoid trapping HLT instructions (v4)
On Sat, Dec 04, 2010 at 08:43:21AM -0600, Anthony Liguori wrote: > In certain use-cases, we want to allocate guests fixed time slices where idle > guest cycles leave the machine idling. There are many approaches to achieve > this but the most direct is to simply avoid trapping the HLT instruction which > lets the guest directly execute the instruction putting the processor to > sleep. 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! Also, just curious how this would work for idle vcpus that use mwait rather than hlt. - vatsa -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
