Received: by 10.223.176.5 with SMTP id f5csp3029746wra; Mon, 29 Jan 2018 07:49:03 -0800 (PST) X-Google-Smtp-Source: AH8x225DmKgpisiGHg0TD0TeFIi+yZaoKOoAvwoSiCRH99UuuQqloQq8wXttKkLZDCpsTbI2fcyM X-Received: by 10.99.61.205 with SMTP id k196mr20352360pga.370.1517240943307; Mon, 29 Jan 2018 07:49:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517240943; cv=none; d=google.com; s=arc-20160816; b=y4I42qzPU+HTgyu10DG+te6PbHB3RTs7BBTHZmzEEYSxRnW86Vupdlm4QD1sNUgJ1S BAKUN8tMMHVPJxhEU5wwxX972WqzjG/ICXx9aK+FIFCx4FqD94hw7TPZpcUTpTFhpy4I 1wYgf7irru/gEHLnLocR4zor3W6Hz5NzS5yRdQUCVj6uLPfn2fJ0MXFDF4iNNK0PMuZu c4VMW/lJbcE8WsOKqN9jyBDV1J46Fsjp0aKUUrSKRaKLjBWK9p1EYEdU/H1/Vx51FnGV tY8NZAGuEzhyL361EZ/ho1/upfMALLkbvcRmlL26nHFpwRfaJyvPBKbUChe0DQIj7ndW zrKA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=CJ1wWekX3/WRPf7/SRBeLSEvtz9NZCQwo9Kc6JrEnTY=; b=bSrDzWzmoECXSCQn0PIbFDkfOqFs957iijgmXOGqn5LlPZR1N6tPnof6kBNOf8mZXt 87ek2b/pRF45Dr90tBAgFW9XaHT0ztgxtLXH/8TkSTo3ReiubHH7ggk0FCSwnadYgrAf TvUtD76Vr5l6W/j/12LBjflxkypX+DGybF9yPYtagdmedyFeeJzHsQiLXXkGqUuamKlk 2K/G4md/GvcRCPuWUbQqNrqt/DO6yRp3WP6KkGCD1GdoGUQGaQYGWBCeGSKIKlwVGCfb peBz+LHfhVvb45XQVBJjlua5z5UoE6AGWw+mu6vXlRRWA1PsNu51+mF8LUF4mD1NpmuF ES9g== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=qig9c+Fe; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m11-v6si9400656pla.712.2018.01.29.07.48.48; Mon, 29 Jan 2018 07:49:03 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=qig9c+Fe; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752046AbeA2Prv (ORCPT + 99 others); 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 ); Mon, 29 Jan 2018 10:47:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=CJ1wWekX3/WRPf7/SRBeLSEvtz9NZCQwo9Kc6JrEnTY=; b=qig9c+FeGxJFz+QkZ/Y9qXGBn fJl2caVSI+F98P6RAntreP5YJXBghDA+HaXRGVq3clfSfATPYTklfJn8iNWwQ9Nf9UXCW/ix1MQhD uh9ynF3YR1Bw0cwj1lDaD+qcDo35kA9msfRT6Yh0d+D6eZEnxsIzST3xEKVLqvnxH52EVLEVr3PMz xhbAelq0dSewtz8eYFG99r/1xelENTYtlLz1M+Xl2AWmxZEFfgWej1Ws6v7Txp2mGYqwSXZ426rOx ZEHjKhCgO31qGzznrZEb3r6x6VHjOpchsyjWoH9kbVuc1oHkkjGPmpa24w6ZDX7D8d/K1PARHkzK0 +5r4nqhXA==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=hirez.programming.kicks-ass.net) by bombadil.infradead.org with esmtpsa (Exim 4.89 #1 (Red Hat Linux)) id 1egBep-0001Db-4l; Mon, 29 Jan 2018 15:47:43 +0000 Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 6F8C42013E23F; Mon, 29 Jan 2018 16:47:40 +0100 (CET) Date: Mon, 29 Jan 2018 16:47:40 +0100 From: Peter Zijlstra To: Frederic Weisbecker Cc: Luiz Capitulino , Ingo Molnar , LKML , Chris Metcalf , Thomas Gleixner , Christoph Lameter , "Paul E . McKenney" , Wanpeng Li , Mike Galbraith , Rik van Riel 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 Precedence: bulk List-ID: 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.