Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965487AbbFCRTz (ORCPT ); Wed, 3 Jun 2015 13:19:55 -0400 Received: from mail-wg0-f47.google.com ([74.125.82.47]:33662 "EHLO mail-wg0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933153AbbFCRGa (ORCPT ); Wed, 3 Jun 2015 13:06:30 -0400 Date: Wed, 3 Jun 2015 19:06:25 +0200 From: Ingo Molnar To: Thomas Gleixner Cc: Linus Torvalds , Adrian Hunter , LKML , Andy Lutomirski , Andi Kleen , the arch/x86 maintainers , "H. Peter Anvin" , Len Brown Subject: Re: [PATCH RFC] x86, tsc: Allow for high latency in quick_pit_calibrate() Message-ID: <20150603170625.GA14389@gmail.com> References: <1432194944-29087-1-git-send-email-adrian.hunter@intel.com> <20150603062054.GA23303@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2168 Lines: 49 * Thomas Gleixner wrote: > On Wed, 3 Jun 2015, Linus Torvalds wrote: > > On Tue, Jun 2, 2015 at 11:20 PM, Ingo Molnar wrote: > > > > > > 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. > > At least it used to. Not sure if it still does. So I googled around a bit, and it's not as clear-cut as I thought initially: it appears that if the BIOS enables the HPET then modern Windows (Windows 7 and later) will use it, but there are problems and Windows XP (the largest installed base) used the TSC+acpipm. (two other lovely clocks) > > We've had issues with HPET, but for calibration it might very well be the > > right thing to do. > > Right. The issues we had were on the clock events side caused by the match > register delayed writes. I've never seen a bug report about the frequency being > completely wrong, except for crap values which we filter out. Though, HPET > period can be off by more than 500ppm, but I don't think that matters anymore > for timekeeping as we switch to TSC only after the long term calibration. The > quick calibration is just for getting the TSC frequency roughly correct for > udelay. Yes - so the frequency being off due to production variances (or sheer firmware incompetence) isn't a big deal in itself: having boot-to-boot jitter during fast calibration would be, and that's the big question. The nice thing about the PIT calibration is that it usually provides very little jitter, so that driver delays/etc. are as boot-to-boot identical as possible. Anyway, the HPET might be worth an attempt - but I'd not be surprised if we discovered another rotten apple ... Thanks, Ingo -- 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/