From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [PATCH] xen: always set the sched clock as unstable Date: Mon, 16 Apr 2012 11:17:59 -0400 Message-ID: <20120416151759.GI1903@phenom.dumpdata.com> References: <1334341255-11153-1-git-send-email-david.vrabel@citrix.com> <4F8C1F6D020000780007E11A@nat28.tlf.novell.com> <4F8C33E0.2080007@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <4F8C33E0.2080007@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: David Vrabel Cc: "Tim (Xen.org)" , "linux-kernel@vger.kernel.org" , xen-devel , Jan Beulich , Sheng Yang , Thomas Gleixner List-Id: xen-devel@lists.xenproject.org On Mon, Apr 16, 2012 at 03:59:44PM +0100, David Vrabel wrote: > On 16/04/12 12:32, Jan Beulich wrote: > >>>> On 13.04.12 at 20:20, David Vrabel wrote: > >> From: David Vrabel > >> > >> The sched clock was considered stable based on the capabilities of the > >> underlying hardware. This does not make sense for Xen PV guests as: In regards to PV dom0 is this still the case? Asking b/c your patch will make dom0 be in the same category. > >> a) the hardware TSC is not used directly as the clock source; and b) > >> guests may migrate to hosts with different hardware capabilities. > >> > >> It is not clear to me whether the Xen clock source is supposed to be > >> stable and whether it should be stable across migration. For a clock I thought it was dependent on XEN_DOMCTL_settscinfo: - whether it gets emulated, or the guest can do rdtsc or pvrdtsc? Which I think is determined by some 'timer=X' option in the guest config? > >> source to be stable it must be: a) monotonic; c) synchronized across > >> CPUs; and c) constant rate. > > Tim, Thomas, can you comment on the above paragraph? Is it correct? > > >> There have also been reports of systems with apparently unstable > >> clocks where clearing sched_clock_stable has fixed problems with > >> migrated VMs hanging. > >> > >> So, always set the sched clock as unstable when using the Xen clock > >> source. > >> > >> Signed-off-by: David Vrabel > >> --- > >> arch/x86/xen/time.c | 1 + > >> 1 files changed, 1 insertions(+), 0 deletions(-) > >> > >> diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c > >> index 0296a95..8469b5a 100644 > >> --- a/arch/x86/xen/time.c > >> +++ b/arch/x86/xen/time.c > >> @@ -473,6 +473,7 @@ static void __init xen_time_init(void) > >> do_settimeofday(&tp); > >> > >> setup_force_cpu_cap(X86_FEATURE_TSC); > >> + sched_clock_stable = 0; > > > > This, unfortunately, is not sufficient afaict: If a CPU gets brought up > > post-boot, the variable may need to be cleared again. Instead you > > ought to call mark_tsc_unstable(). > > Yeah, mark_tsc_unstable() is the right thing to do. > > David