On Thu, Jul 22, 2021, Li,Rongqing wrote: > > > > SMT siblings share caches and other hardware, halt polling will > > > > degrade its sibling performance if its sibling is busy > > > > > > Do you have any real scenario benefits? As the polling nature, some > > > cloud providers will configure to their preferred balance of cpu usage > > > and performance, and other cloud providers for their NFV scenarios > > > which are more sensitive to latency are vCPU and pCPU 1:1 pin,you > > > destroy these setups. > > > > > > Wanpeng > > > > > Run a copy (single thread) Unixbench, with or without a busy poll program in > its SMT sibling, and Unixbench score can lower 1/3 with SMT busy polling > program Rather than disallowing halt-polling entirely, on x86 it should be sufficient to simply have the hardware thread yield to its sibling(s) via PAUSE. It probably won't get back all performance, but I would expect it to be close. This compiles on all KVM architectures, and AFAICT the intended usage of cpu_relax() is identical for all architectures. diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index 6980dabe9df5..a07ecb3c67fb 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -3111,6 +3111,7 @@ void kvm_vcpu_block(struct kvm_vcpu *vcpu) goto out; } poll_end = cur = ktime_get(); + cpu_relax(); } while (kvm_vcpu_can_poll(cur, stop)); }