Messages in this thread | | | Subject | Re: [PATCH RFC 0/7] kvm pvtimer | From | Quan Xu <> | Date | Thu, 14 Dec 2017 10:32:38 +0800 |
| |
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 <bn0418@gmail.com> >>>> >>>> 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
| |