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 S1752051AbeA2Prv (ORCPT <rfc822;w@1wt.eu>);
        Mon, 29 Jan 2018 10:47:51 -0500
Received: from bombadil.infradead.org ([65.50.211.133]:52207 "EHLO
        bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751412AbeA2Pru (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Mon, 29 Jan 2018 10:47:50 -0500
Date: Mon, 29 Jan 2018 16:47:40 +0100
From: Peter Zijlstra <peterz@infradead.org>
To: Frederic Weisbecker <frederic@kernel.org>
Cc: Luiz Capitulino <lcapitulino@redhat.com>,
        Ingo Molnar <mingo@kernel.org>, LKML <linux-kernel@vger.kernel.org>,
        Chris Metcalf <cmetcalf@mellanox.com>,
        Thomas Gleixner <tglx@linutronix.de>, Christoph Lameter <cl@linux.com>,
        "Paul E . McKenney" <paulmck@linux.vnet.ibm.com>,
        Wanpeng Li <kernellwp@gmail.com>, Mike Galbraith <efault@gmx.de>,
        Rik van Riel <riel@redhat.com>
Subject: Re: [GIT PULL] isolation: 1Hz residual tick offloading v4
Message-ID: <20180129154740.GV2269@hirez.programming.kicks-ass.net>
References: <1516320140-13189-1-git-send-email-frederic@kernel.org>
 <20180124104608.038fb212@redhat.com>
 <20180129011024.GA2942@lerouge>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20180129011024.GA2942@lerouge>
User-Agent: Mutt/1.9.2 (2017-12-15)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, Jan 29, 2018 at 02:10:26AM +0100, Frederic Weisbecker wrote:

> It's beyond the scope of this patchset but indeed that's right, I run my
> kernels with tsc=reliable because my CPUs don't have the TSC_RELIABLE flag.
> That's the only way I found to shutdown the tick completely on my test
> machine, otherwise I keep having that clocksource watchdog.
> 
> You can try "tsc=reliable" but that's at your own risks and it's hard
> to tell what exactly are those risks depending on your CPU model (and
> perhaps BIOS?).

BIOS, anything Nehalem and later, BIOS monkeys are to blame. There is
one exception to that, and that is very large socket count machines, and
these people typically already know what they got themselves into.

If your machine never triggers the watchdog with your workload, booting
with tsc=reliable is safe (for that workload).

But if you trip the watchdog, booting with tsc=reliable is a very bad
idea indeed.