From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753036AbdA3MM3 (ORCPT ); Mon, 30 Jan 2017 07:12:29 -0500 Received: from david.siemens.de ([192.35.17.14]:45639 "EHLO david.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752578AbdA3MMW (ORCPT ); Mon, 30 Jan 2017 07:12:22 -0500 Date: Mon, 30 Jan 2017 13:13:01 +0100 From: Henning Schild To: Thomas Gleixner Cc: LKML , Ingo Molnar , Peter Zijlstra , Borislav Petkov , Yinghai Lu Subject: Re: [3/8] x86/tsc: Store and check TSC ADJUST MSR Message-ID: <20170130131301.7ddae08d@md1em3qc> In-Reply-To: References: <20161119134017.655323776@linutronix.de> <20170127143632.4f56d927@md1em3qc> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 30 Jan 2017 11:20:25 +0100 Thomas Gleixner wrote: > Henning, > > On Fri, 27 Jan 2017, Henning Schild wrote: > > > > did you by any chance look into TSC synchronization by adjusting the > > absolute value (MSR_IA32_TSC) as well? As far as i have seen Linux > > did that a long time ago and eventually it was stopped because it > > caused more harm than good. > > I was involved in both developing the TSC sync patches and ripping > them out again. > > The problem with writing TSC directly is that you really _CANNOT_ > reliably handle run-time differences and SMI/NMI induced deltas. With > the adjust MRS it's a halfways sane thing to do, except for the > brokeness of that botch job vs. the TSC deadline timer. > > > The ADJUST MSR offers an easy way to synchronize, still taking care > > of all the special cases resulted in an 8-patch series. Synching > > without that using the absolute value is likely much harder, but > > that series might be a good foundation. > > I'm not even thinking about bringing the pure TSC based sync back. > > > The big question is whether we can rely on all future CPUs to > > support that MSR. Do "new MSRs" disappear again at some point? If we > > can not rely on the ADJUST MSR, now might be a good time to revisit > > the idea of synching the absolute values. > > There is nothing you can ever be sure about, but I doubt that the > ADJUST MSR is going to vanish. That sounds very much like i expected. But assuming the MSR has come to stay, the problem should be solved for recent kernels and Intel-CPUs. The AMD-Manual from 12/16 does not mention that MSR. I do not have access to an AMD machine. But i can only assume that bigger machines also suffer from async TSCs and basically all fall back to HPET. > > I remember having read somewhere that this series might get > > backported to longterm kernels, what is the status on that? > > No idea. > > Thanks, Thanks a lot! Henning