From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752724AbbDXLuH (ORCPT <rfc822;w@1wt.eu>);
	Fri, 24 Apr 2015 07:50:07 -0400
Received: from www.linutronix.de ([62.245.132.108]:41048 "EHLO
	Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751209AbbDXLuE (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Fri, 24 Apr 2015 07:50:04 -0400
Date: Fri, 24 Apr 2015 13:50:05 +0200 (CEST)
From: Thomas Gleixner <tglx@linutronix.de>
To: Andi Kleen <ak@linux.intel.com>
cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>,
        Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
        x86@kernel.org, Don Zickus <dzickus@redhat.com>,
        Frederic Weisbecker <fweisbec@gmail.com>,
        Adrian Hunter <adrian.hunter@intel.com>,
        Anton Blanchard <anton@samba.org>,
        Michael Ellerman <mpe@ellerman.id.au>, linux-kernel@vger.kernel.org,
        stable@vger.kernel.org
Subject: Re: [PATCH v1] watchdog: Use a reference cycle counter to avoid
 scaling issues
In-Reply-To: <20150424095906.GL13605@tassilo.jf.intel.com>
Message-ID: <alpine.DEB.2.11.1504241344310.13914@nanos>
References: <1429801408-11309-1-git-send-email-alexander.shishkin@linux.intel.com> <alpine.DEB.2.11.1504232153080.13914@nanos> <20150423203236.GJ13605@tassilo.jf.intel.com> <alpine.DEB.2.11.1504232242510.13914@nanos> <20150424005133.GK13605@tassilo.jf.intel.com>
 <alpine.DEB.2.11.1504240957570.13914@nanos> <20150424095906.GL13605@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
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, 24 Apr 2015, Andi Kleen wrote:
> > There are better ways to do that than using heuristics. We have to
> > deal with 3 variants of the reference counter:
> > 
> > 1) Core and Atom: counts bus cycles and we know that frequency already
> >    	    	  from the local apic calibration
> > 
> > 2) Nehalem, Westmere: Same as TSC
> > 
> > 3) Sandybridge and later:  XCLK which is 100MHz
> > 
> > No magic calibration, just use the information which we have on our
> > hands already.
> 
> This is a really bad idea. We basically would need to maintain a big
> switch with model numbers, with new cases added for every new CPU.
> Would be a maintenance nightmare.

Nonsense. We have already enough family specific switch cases which
need to be maintained for every new cpu anyway. So they can simply
provide that extra bit of information. It's neither rocket science nor
a nightmare.

We don't need to calibrate stuff which we can access by simpler means.

Thanks,

	tglx