From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: cpufreq status information Date: Mon, 08 Sep 2008 15:30:48 +0100 Message-ID: <48C55338.76E4.0078.0@novell.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser , Kevin Tian Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org >>> Keir Fraser 08.09.08 16:00 >>> >After all, guest performance is at least as affected by CPU (and other >resources) contention from other guests as it is by power-management >governors in the hyeprvisor. Indeed, if the governors are doing their job >right then guest performance should not be considerably impacted by them >even in absolute terms. Right you say 'if' - what if not? How do I tell, especially when I can't = touch the system and easily put a patched hypervisor and/or kernel on. If we get a complaint from a customer that he thinks frequency scaling doesn't do what it's expected to, we'll need to have a simple mechanism at hand to determine what's going on with his box. And even for development purposes I think a one-look proof that things work as expected is quite useful (I'm doing the same for a few other basic things - the interrupt rate being one of those that helped spot problems that otherwise would have gone unnoticed for a much longer period of time). Jan