From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: [dpdk-dev] [PATCH v4 00/10] VM Power Management Date: Fri, 12 Dec 2014 17:13:55 +0100 Message-ID: <548B1443.6060706@redhat.com> References: <1412003903-9061-1-git-send-email-alan.carew@intel.com> <0E29434AEE0C3A4180987AB476A6F6306D2B6443@IRSMSX109.ger.corp.intel.com> <548B00B3.8040201@redhat.com> <6597811.ARdDfzU0XI@xps13> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: "De Lara Guarch, Pablo" , dev@dpdk.org, "Carew, Alan" , qemu-devel@nongnu.org To: Thomas Monjalon Return-path: In-Reply-To: <6597811.ARdDfzU0XI@xps13> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Id: dev.dpdk.org On 12/12/2014 17:10, Thomas Monjalon wrote: > > Ok, this looks specific enough that an out-of-band solution within DPDK > > sounds like the best approach. It seems unnecessary to involve the > > hypervisor (neither KVM nor QEMU). > > Paolo, I don't understand why you don't imagine controlling frequency scaling > of a pinned vCPU transparently? Probably because I don't imagine controlling frequency scaling from the application on bare metal, either. :) It seems to me that this is just working around limitations of the kernel. Paolo > In my understanding, we currently cannot control frequency scaling without > knowing wether we are in a VM or not.