From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752626AbdBBR7B (ORCPT ); Thu, 2 Feb 2017 12:59:01 -0500 Received: from mx1.redhat.com ([209.132.183.28]:33880 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752502AbdBBR64 (ORCPT ); Thu, 2 Feb 2017 12:58:56 -0500 Message-Id: <20170202174755.946578704@redhat.com> User-Agent: quilt/0.60-1 Date: Thu, 02 Feb 2017 15:47:55 -0200 From: Marcelo Tosatti To: kvm@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Paolo Bonzini , Radim Krcmar , "Rafael J. Wysocki" , Viresh Kumar Subject: [patch 0/3] KVM CPU frequency change hypercalls X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Thu, 02 Feb 2017 17:58:57 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.