Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757185AbYJIVF0 (ORCPT ); Thu, 9 Oct 2008 17:05:26 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754960AbYJIVFL (ORCPT ); Thu, 9 Oct 2008 17:05:11 -0400 Received: from mx2.redhat.com ([66.187.237.31]:39735 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754276AbYJIVFK (ORCPT ); Thu, 9 Oct 2008 17:05:10 -0400 Message-ID: <48EE71A9.2010907@redhat.com> Date: Thu, 09 Oct 2008 17:03:37 -0400 From: Chris Snook Organization: Red Hat User-Agent: Thunderbird 2.0.0.16 (X11/20080723) MIME-Version: 1.0 To: Alok kataria CC: Thomas Gleixner , Jeff Hansen , torvalds@linux-foundation.org, linux-kernel@vger.kernel.org, mingo@elte.hu, akataria@vmware.com Subject: Re: [PATCH] Re: x86_32 tsc/pit and hrtimers References: <48ED1728.5060708@redhat.com> <48ED2A89.3000902@redhat.com> <48EE4FC4.7070902@redhat.com> <35f686220810091345h253d71e8s4fe9d7ea8e636ccc@mail.gmail.com> In-Reply-To: <35f686220810091345h253d71e8s4fe9d7ea8e636ccc@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1540 Lines: 34 Alok kataria wrote: > On Thu, Oct 9, 2008 at 12:53 PM, Thomas Gleixner wrote: >> On Thu, 9 Oct 2008, Jeff Hansen wrote: >> >>> OK, so are we all agreed that something like clocksource_trust=tsc would be >>> the best? >> No, it's per affected device: tsc=trust or tsc=stable or whatever >> unintuitive name we want to come up. And it is a modification to TSC >> not to the clocksource layer. > > Yep, this is cool. I too have a patch in my local tree which does a > similar thing i have a tsc_reliable flag which is set right now only > when we are running under a VMware hypervisor. > Along with marking the no_verify flag for TSC, this patch of mine also > skips the TSC synchornization checks. > > The TSC synchronization loop which is run whenever a new cpu is > brought up is not actually needed on systems which are known to have a > reliable TSC. TSC between 2 cpus can be off by a marginal value on such > systems and thats okay for timekeeping, since we do check for tsc going > back in read_tsc. > > Can this reasoning be included and synchronization skipped for all > these systems with reliable aka trustworthy TSC's ? In general, no. Not all hardware/hypervisors behave this way, even when the TSC is otherwise stable once synchronized. -- Chris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/