Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752186AbbFBT6k (ORCPT ); Tue, 2 Jun 2015 15:58:40 -0400 Received: from www.linutronix.de ([62.245.132.108]:52903 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751493AbbFBT61 (ORCPT ); Tue, 2 Jun 2015 15:58:27 -0400 Date: Tue, 2 Jun 2015 21:58:26 +0200 (CEST) From: Thomas Gleixner To: Andi Kleen cc: Andy Lutomirski , Adrian Hunter , LKML , Linus Torvalds , X86 ML , "H. Peter Anvin" , Len Brown Subject: Re: [PATCH RFC] x86, tsc: Allow for high latency in quick_pit_calibrate() In-Reply-To: <20150602194350.GN1187@tassilo.jf.intel.com> Message-ID: References: <1432194944-29087-1-git-send-email-adrian.hunter@intel.com> <20150602194350.GN1187@tassilo.jf.intel.com> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001,URIBL_BLOCKED=0.001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2231 Lines: 58 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). Thanks, tglx -- 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/