Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752090AbdLNMGY (ORCPT ); Thu, 14 Dec 2017 07:06:24 -0500 Received: from mail-ot0-f195.google.com ([74.125.82.195]:46790 "EHLO mail-ot0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751753AbdLNMGW (ORCPT ); Thu, 14 Dec 2017 07:06:22 -0500 X-Google-Smtp-Source: ACJfBosevUE/jMOS11lmElYd+BnACUn0hxGiGqkC0ZWIdlijqGJOa/GmMiXvlCEIXk06f/ZmQMOLoA== Subject: Re: [PATCH RFC 0/7] kvm pvtimer To: Paolo Bonzini , Konrad Rzeszutek Wilk Cc: Radim Krcmar , Yang Zhang , kvm , LKML , Ben Luo References: <1512722390-3654-1-git-send-email-quan.xu0@gmail.com> <20171208151014.GE12069@x230.dumpdata.com> <20171213162800.GS10097@char.us.oracle.com> <78ebabd2-cc38-2694-b104-c5e0230aba15@redhat.com> From: Quan Xu Message-ID: <7aef193f-900d-e8b1-35f7-2373ffdfa147@gmail.com> Date: Thu, 14 Dec 2017 20:06:14 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <78ebabd2-cc38-2694-b104-c5e0230aba15@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1107 Lines: 34 On 2017/12/14 19:56, Paolo Bonzini wrote: > On 13/12/2017 17:28, Konrad Rzeszutek Wilk wrote: >> 1) VM idle path and network req/resp services: >> >> Does this go away if you don't hit the idle path? Meaning if you >> loop without hitting HLT/MWAIT? I am assuming the issue you are facing >> is the latency - that is first time the guest comes from HLT and >> responds to the packet the latency is much higher than without? >> >> And the arming of the timer? >> 2) process context switches. >> >> Is that related to the 1)? That is the 'schedule' call and the process >> going to sleep waiting for an interrupt or timer? >> >> This all sounds like issues with low-CPU usage workloads where you >> need low latency responses? > Even high-CPU usage, as long as there is a small idle time. The cost of > setting the TSC deadline timer twice is about 3000 cycles. > > However, I think Amazon's approach of not intercepting HLT/MWAIT/PAUSE > can recover most of the performance and it's way less intrusive.   Paolo, could you share the Amazon's patch or the LML link? thanks. Quan > Thanks, > > Paolo >