Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752018AbbFBUD5 (ORCPT ); Tue, 2 Jun 2015 16:03:57 -0400 Received: from mail-la0-f43.google.com ([209.85.215.43]:33875 "EHLO mail-la0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751158AbbFBUDr (ORCPT ); Tue, 2 Jun 2015 16:03:47 -0400 MIME-Version: 1.0 In-Reply-To: References: <1432194944-29087-1-git-send-email-adrian.hunter@intel.com> <20150602194350.GN1187@tassilo.jf.intel.com> From: Andy Lutomirski Date: Tue, 2 Jun 2015 13:03:25 -0700 Message-ID: Subject: Re: [PATCH RFC] x86, tsc: Allow for high latency in quick_pit_calibrate() To: Thomas Gleixner Cc: Andi Kleen , Adrian Hunter , LKML , Linus Torvalds , X86 ML , "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: 2551 Lines: 59 On Tue, Jun 2, 2015 at 12:58 PM, Thomas Gleixner wrote: > On Tue, 2 Jun 2015, Andi Kleen wrote: >> On Tue, Jun 02, 2015 at 12:41:27PM -0700, Andy Lutomirski wrote: >> > On Tue, Jun 2, 2015 at 12:33 PM, Thomas Gleixner wrote: >> > > On Thu, 21 May 2015, Adrian Hunter wrote: >> > > >> > >> If it takes longer than 12us to read the PIT counter lsb/msb, >> > >> then the error margin will never fall below 500ppm within 50ms, >> > >> and Fast TSC calibration will always fail. >> > > >> > > So finally the legacy PIT emulation takes longer than the 30 years old >> > > hardware implementation. Progress! >> > > >> > >> This patch detects when that will happen and switches to using >> > >> a slightly different algorithm that takes advantage of the PIT's >> > >> latch comand. >> > > >> > > Is there really no smarter way to figure out the TSC frequency on >> > > modern systems? >> > >> > I just asked Len this question yesterday. intel_pstate can do it, >> > although the algorithm is a bit gross. > > Well, the algorithm for that slow PIT emulation thing is definitely > not from the straight forward kind either. > >> intel_pstate needs to know the model number. If you know the >> model number sure you can do a lot better (e.g. using the >> ref-clock fixed counter or some other methods) >> >> But if you don't you need something else. And at some point >> the only thing left over is the PIT. > > Right, and if we dont have a way to readout the stuff because the > kernel does not yet have support for that particular model it falls > back to PIT slow path in the worst case. > > That's better than having another weird calibration routine which > might be outdated with the next generation of PIT emulation. We've > been there with the HPET deferred writes already. No need to have more > of this nonsense. > > It's about time that Intel gets its act together and provides a proper > architected way to figure that out. Though I fear that will require > another 15 years of yelling (IIRC that was the time it took to get a > constant frequency TSC). There's the code in tsc_msr.c. It should be relatively straightforward to extend it to cover everything that intel_pstate supports. But yes, Intel should add an MSR that gives the frequency in Hz. --Andy -- 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/