From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcelo Tosatti Subject: Re: [patch 0/7] force the TSC unreliable by reporting C2 state Date: Wed, 18 Jun 2008 17:40:42 -0300 Message-ID: <20080618204042.GA15981@dmt.cnet> References: <20080618164205.108219607@localhost.localdomain> <48596B85.7090008@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Avi Kivity , kvm@vger.kernel.org To: Anthony Liguori Return-path: Received: from mx1.redhat.com ([66.187.233.31]:60335 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754545AbYFRUlA (ORCPT ); Wed, 18 Jun 2008 16:41:00 -0400 Content-Disposition: inline In-Reply-To: <48596B85.7090008@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: On Wed, Jun 18, 2008 at 03:09:41PM -0500, Anthony Liguori wrote: > Marcelo Tosatti wrote: >> Avi, I don't think this causes such a huge performance regression. NOHZ >> makes the frequency of timer reads go down significantly. >> > > Have we yet determined why the TSC is so unstable in the first place? > In theory, it should be relatively stable on single-node Intel and > Barcelona chips. If the host enters C2/C3, or changes CPU frequency, it becomes unreliable as a clocksource and there's no guarantee the guest will detect that. Also, as mentioned earlier, large systems with clustered APIC have unstable TSC. We _could_ hook this fake-C2-state thing to the host TSC reliability: 1) Hook into Linux's mark_tsc_unstable(). 2) On migration check if the destination host is using the TSC, if not, force a faked-C2-state. Problem with 2) is that not all guests honour the ACPI _CST package notification (which would change C2's latency time from an unusable value to something usable). And now I don't think assuming the _CST notification to work is a good thing (after we found out that for ex. Ubuntu 7.10 kernel ignores it).