All of lore.kernel.org
 help / color / mirror / Atom feed
From: Henning Schild <henning.schild@siemens.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@kernel.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Borislav Petkov <bp@alien8.de>, Yinghai Lu <yinghai@kernel.org>
Subject: Re: [3/8] x86/tsc: Store and check TSC ADJUST MSR
Date: Mon, 30 Jan 2017 13:13:01 +0100	[thread overview]
Message-ID: <20170130131301.7ddae08d@md1em3qc> (raw)
In-Reply-To: <alpine.DEB.2.20.1701301113120.3606@nanos>

On Mon, 30 Jan 2017 11:20:25 +0100
Thomas Gleixner <tglx@linutronix.de> 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

  reply	other threads:[~2017-01-30 12:12 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-19 13:47 [patch 0/8] x86/tsc: Utilize TSC_ADJUST MSR Thomas Gleixner
2016-11-19 13:47 ` [patch 1/8] x86/tsc: Use X86_FEATURE_TSC_ADJUST in detect_art() Thomas Gleixner
2016-11-29 16:46   ` [tip:x86/timers] " tip-bot for Thomas Gleixner
2016-11-29 18:28   ` tip-bot for Thomas Gleixner
2016-11-19 13:47 ` [patch 2/8] x86/tsc: Detect random warps Thomas Gleixner
2016-11-29 16:46   ` [tip:x86/timers] " tip-bot for Thomas Gleixner
2016-11-29 18:28   ` tip-bot for Thomas Gleixner
2016-11-19 13:47 ` [patch 3/8] x86/tsc: Store and check TSC ADJUST MSR Thomas Gleixner
2016-11-29 16:47   ` [tip:x86/timers] " tip-bot for Thomas Gleixner
2016-11-29 18:29   ` tip-bot for Thomas Gleixner
2017-01-27 13:36   ` [3/8] " Henning Schild
2017-01-30 10:20     ` Thomas Gleixner
2017-01-30 12:13       ` Henning Schild [this message]
2017-01-30 13:04         ` Thomas Gleixner
2017-01-30 15:58           ` Borislav Petkov
2016-11-19 13:47 ` [patch 4/8] x86/tsc: Verify TSC_ADJUST from idle Thomas Gleixner
2016-11-20 13:10   ` Peter Zijlstra
2016-11-21  8:16     ` Thomas Gleixner
2016-11-21 11:06       ` Peter Zijlstra
2016-11-29  9:17         ` Thomas Gleixner
2016-11-29 14:25           ` Ingo Molnar
2016-11-21 22:57   ` Andi Kleen
2016-11-29 16:47   ` [tip:x86/timers] " tip-bot for Thomas Gleixner
2016-11-29 18:29   ` tip-bot for Thomas Gleixner
2016-11-19 13:47 ` [patch 5/8] x86/tsc: Sync test only for the first cpu in a package Thomas Gleixner
2016-11-29 16:48   ` [tip:x86/timers] " tip-bot for Thomas Gleixner
2016-11-29 18:30   ` tip-bot for Thomas Gleixner
2016-11-19 13:47 ` [patch 6/8] x86/tsc: Move sync cleanup to a safe place Thomas Gleixner
2016-11-29 16:48   ` [tip:x86/timers] " tip-bot for Thomas Gleixner
2016-11-29 18:30   ` tip-bot for Thomas Gleixner
2016-11-19 13:47 ` [patch 7/8] x86/tsc: Prepare warp test for TSC adjustment Thomas Gleixner
2016-11-29 16:49   ` [tip:x86/timers] " tip-bot for Thomas Gleixner
2016-11-29 18:31   ` tip-bot for Thomas Gleixner
2016-11-19 13:47 ` [patch 8/8] x86/tsc: Try to adjust TSC if sync test fails Thomas Gleixner
2016-11-29 16:49   ` [tip:x86/timers] " tip-bot for Thomas Gleixner
2016-11-29 18:31   ` tip-bot for Thomas Gleixner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170130131301.7ddae08d@md1em3qc \
    --to=henning.schild@siemens.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=bp@alien8.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=yinghai@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.