Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752406AbbFCEUP (ORCPT ); Wed, 3 Jun 2015 00:20:15 -0400 Received: from mail-ig0-f169.google.com ([209.85.213.169]:35286 "EHLO mail-ig0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751330AbbFCEUJ (ORCPT ); Wed, 3 Jun 2015 00:20:09 -0400 MIME-Version: 1.0 In-Reply-To: References: <1432194944-29087-1-git-send-email-adrian.hunter@intel.com> Date: Tue, 2 Jun 2015 21:20:06 -0700 X-Google-Sender-Auth: ADx8jLVWmfyI1C0nsBpKmkezWKU Message-ID: Subject: Re: [PATCH RFC] x86, tsc: Allow for high latency in quick_pit_calibrate() From: Linus Torvalds To: Thomas Gleixner Cc: 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: 2193 Lines: 47 On Tue, Jun 2, 2015 at 12:33 PM, Thomas Gleixner wrote: > > Is there really no smarter way to figure out the TSC frequency on > modern systems? Sadly, if there is, we have yet to find it. I don't think the mentioned intel_pstate thing gets it right either. Yes, it gets some "theoretical frequency", given the pstate and the scaling factor, but that assumes the base clock (BCLK) is something trustworthy. That's a big assumption, and I can pretty much guarantee it's not a valid assumption. I'm sure that's the *common* case, but how much do you want to bet that some motherboard makers noticed that they get good press from good benchmark numbers, and that they can tweak BCLK a bit higher than the competition? "Oooh, motherboard from Xyz is really good, it's 1% faster than the competition". Or all those overclockers? Yes, some of them buy unlocked CPU's and leave BCLK alone. Or maybe they do both. Or maybe they just buy locked CPU's and tweak BCLK. The only *well-defined* clock in a modern PC seems to still remain the PIT. Yes, it's very sad. But all the other clocks tend to be untrustworthy for various reasons, like "frequency is stated in the ACPI tables", which we know is basically just a fantasy that may be right *most* of the time, but I can almost guarantee that some BIOS guys decided that they can get slightly better random benchmark numbers by "tweaking" the truth a bit. It's the "BIOS version" of overclocking by increasing BCLK - lie about the PM frequency, so that any benchmark that times things that way will give better numbers.. But pretty much nobody messes up the PIT. That will change, just because it's clearly getting to the point where people are just emulating it, and it's probably not going to be any more trustworthy than anything else. So rather than get a new and truly trustworthy reference clock, the patch makes me suspect we're losing the old one... 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/