Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752002AbdLNCcr (ORCPT ); Wed, 13 Dec 2017 21:32:47 -0500 Received: from mail-ot0-f193.google.com ([74.125.82.193]:41505 "EHLO mail-ot0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751802AbdLNCcp (ORCPT ); Wed, 13 Dec 2017 21:32:45 -0500 X-Google-Smtp-Source: ACJfBov2HmSC78IUiSjsYCU2IqoyIy4G5OSXHhq+nmPcHQb5uD8ki+Wg2HFGsnxCmUuRDxpSxfMD2w== Subject: Re: [PATCH RFC 0/7] kvm pvtimer To: Konrad Rzeszutek Wilk Cc: Paolo Bonzini , 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> From: Quan Xu Message-ID: <462b7e38-da27-fcea-9f02-8f090d2d8603@gmail.com> Date: Thu, 14 Dec 2017 10:32:38 +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: <20171213162800.GS10097@char.us.oracle.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: 1650 Lines: 47 On 2017/12/14 00:28, Konrad Rzeszutek Wilk wrote: > On Wed, Dec 13, 2017 at 11:25:13PM +0800, Quan Xu wrote: >> On Fri, Dec 8, 2017 at 11:10 PM, Konrad Rzeszutek Wilk < >> konrad.wilk@oracle.com> wrote: >> >>> On Fri, Dec 08, 2017 at 04:39:43PM +0800, Quan Xu wrote: >>>> From: Ben Luo >>>> >>>> This patchset introduces a new paravirtualized mechanism to reduce >>> VM-exit >>>> caused by guest timer accessing. >>> And how bad is this blib in arming the timer? >>> >>> And how often do you get this timer to be armed? OR better yet - what >>> are the workloads in which you found this VMExit to be painful? >>> >>> Thanks. Or better yet - what >>> are the workloads in which you found this VMExit to be painful? >>> >> one painful point is from VM idle path.. >> for some network req/resp services, or benchmark of process context >> switches.. > So: > > 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?   we still hit HLT.. we can use it with https://lkml.org/lkml/2017/8/29/279 .. > 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? yes, > 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? yes,  it is also helpful to some timer-intensive services. Quan