From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752623AbdBCMzC (ORCPT ); Fri, 3 Feb 2017 07:55:02 -0500 Received: from cloudserver094114.home.net.pl ([79.96.170.134]:53138 "EHLO cloudserver094114.home.net.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751944AbdBCMzB (ORCPT ); Fri, 3 Feb 2017 07:55:01 -0500 From: "Rafael J. Wysocki" To: Marcelo Tosatti Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Paolo Bonzini , Radim Krcmar , Viresh Kumar Subject: Re: [patch 0/3] KVM CPU frequency change hypercalls Date: Fri, 03 Feb 2017 13:50:17 +0100 Message-ID: <1585277.2ucOxC55qH@aspire.rjw.lan> User-Agent: KMail/4.14.10 (Linux/4.10.0-rc3+; KDE/4.14.9; x86_64; ; ) In-Reply-To: <20170202174755.946578704@redhat.com> References: <20170202174755.946578704@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thursday, February 02, 2017 03:47:55 PM Marcelo Tosatti wrote: > Implement KVM hypercalls for the guest > to issue frequency changes. > > Current situation with DPDK and frequency changes is as follows: > An algorithm in the guest decides when to increase/decrease > frequency based on the queue length of the device. > > On the host, a power manager daemon is used to listen for > frequency change requests (on another core) and issue these > requests. > > However frequency changes are performance sensitive events because: > On a change from low load condition to max load condition, > the frequency should be raised as soon as possible. > Sending a virtio-serial notification to another pCPU, > waiting for that pCPU to initiate an IPI to the requestor pCPU > to change frequency, is slower and more cache costly than > a direct hypercall to host to switch the frequency. > > If the pCPU where the power manager daemon is running > is not busy spinning on requests from the isolated DPDK vcpus, > there is also the cost of HLT wakeup for that pCPU. > > Moreover, the daemon serves multiple VMs, meaning that > the scheme is subject to additional delays from > queueing of power change requests from VMs. > > A direct hypercall from userspace is the fastest most direct > method for the guest to change frequency and does not suffer > from the issues above. > > The usage scenario for this hypercalls is for pinned vCPUs <-> pCPUs. Any chance to CC this to linux-pm in the future? That would help the review quite a bit. Thanks, Rafael