Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754588AbbFCNno (ORCPT ); Wed, 3 Jun 2015 09:43:44 -0400 Received: from mail-ie0-f170.google.com ([209.85.223.170]:33414 "EHLO mail-ie0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754471AbbFCNnf (ORCPT ); Wed, 3 Jun 2015 09:43:35 -0400 MIME-Version: 1.0 In-Reply-To: <20150603062054.GA23303@gmail.com> References: <1432194944-29087-1-git-send-email-adrian.hunter@intel.com> <20150603062054.GA23303@gmail.com> Date: Wed, 3 Jun 2015 06:43:34 -0700 X-Google-Sender-Auth: LcxQkD47dM4Q6QZ_5dZxpX1mz0Q Message-ID: Subject: Re: [PATCH RFC] x86, tsc: Allow for high latency in quick_pit_calibrate() From: Linus Torvalds To: Ingo Molnar Cc: Thomas Gleixner , Adrian Hunter , LKML , Andy Lutomirski , Andi Kleen , "the arch/x86 maintainers" , "H. Peter Anvin" , Len Brown Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1886 Lines: 43 On Tue, Jun 2, 2015 at 11:20 PM, Ingo Molnar wrote: > > and the HPET, which is pretty good as well, when available. In fact given that > it's required to have a frequency of at least 10 MHz, and (unlike the PIT) has a > pretty wide counter, it could be used for pretty accurate calibration as well that > runs a lot shorter than PIT calibration. Yeah, you're probably right that we should look into at least having the option to use the HPET. That said, the fact that we can read the period from HPET_PERIOD does *not* make me trust it all that much. I suspect that register is just another "filled in by firmware" piece of data. > Given that Windows relies on the > HPET for timekeeping, it might get more attention than the PIT? Does Windows actually do that? Becuase if so, that's just about the strongest argument for HPET there is - it's likely to work, and the frequency is likely to be correct. We've had issues with HPET, but for calibration it might very well be the right thing to do. Does anybody know what the base oscillator for HPET tends to be? Also, some googling shows a vmware paper that is not that impressed with the HPET. The good thing about the PIT is that it's just *specified* to be driven off a real crystal running at a very fixed frequency. There's no gray areas there. Sure, virtualization can screw it up (but will likely screw up other higher-resolution clocks even more), and hw designers can cause problems, but it's been pretty reliable. (Yeah, the CMOS RTC clock should be too, as George Spelvin points out. That might be worth looking at too). Linus -- 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/