linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Roland Scheidegger <rscheidegger_lists@hispeed.ch>
Cc: LKML <linux-kernel@vger.kernel.org>,
	x86@kernel.org, Peter Zijlstra <peterz@infradead.org>,
	Borislav Petkov <bp@alien8.de>,
	Bruce Schlobohm <bruce.schlobohm@intel.com>,
	Kevin Stanton <kevin.b.stanton@intel.com>,
	Allen Hung <allen_hung@dell.com>
Subject: Re: [patch 0/2] tsc/adjust: Cure suspend/resume issues and prevent TSC deadline timer irq storm
Date: Wed, 14 Dec 2016 22:40:24 +0100 (CET)	[thread overview]
Message-ID: <alpine.DEB.2.20.1612142225130.5283@nanos> (raw)
In-Reply-To: <alpine.DEB.2.20.1612142124260.5283@nanos>

On Wed, 14 Dec 2016, Thomas Gleixner wrote:
> Positive space, results in timer not firing anymore - at least not in a
> time frame you are willing to wait for.
> 
>      0x0000 0000 8000 0000
> 
> Negative space, results in an interrupt storm.
> 
>      0xffff ffff 0000 0000
>      0xffff fffe 0000 0000
>      0xffff fffd 0000 0000
>      0xffff fffc 0000 0000
>      0xffff fffb 0000 0000
>      ....
> 
> These points are independent of the underlying counter value (cold boot,
> warm boot) and even reproduce after hours of power on reliably.
> 
> And looking at the values makes me wonder about 32bit vs. 64bit wreckage
> combined with sign expansion done wrong. Im really impressed!

And the whole mess stems from the fact that the deadline is not as one
would expect simply compared against the sum of the counter and the adjust
MSR.

No, they subtract the adjust value from the MSR when you write the deadline
and latch the result to compare it against the counter.

So when the following happens:

   ADJUST	= 0
   RDTSC	= 10000000 
   DEADLINE	= 11000000

   ADJUST	=  1000000

   INTERRUPT
   RDTSC	= 12000000

   DEADLINE	= 13000000

   ADJUST	=        0

   INTERRUPT
   RDTSC	= 12000000

So depending on the direction of the adjustment the timer fires late or
early.

Combined with that math wreckage this is a complete disaster. And of course
nothing is documented anywhere and the SDM is outright wrong:

10.5.4.1 TSC-Deadline Mode

  The processor generates a timer interrupt when the value of time-stamp
  counter is greater than or equal to that of IA32_TSC_DEADLINE. It then
  disarms the timer and clear the IA32_TSC_DEADLINE MSR. (Both the time-stamp
  counter and the IA32_TSC_DEADLINE MSR are 64-bit unsigned integers.)

See the example above. 1200000 is neither equal nor greater than 1300000, at
least not in my universe.

I serioulsy doubt that Intel manages it to design at least ONE functional
non broken timer before I retire.

Thanks,

	tglx

  reply	other threads:[~2016-12-14 21:43 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-13 13:14 [patch 0/2] tsc/adjust: Cure suspend/resume issues and prevent TSC deadline timer irq storm Thomas Gleixner
2016-12-13 13:14 ` [patch 1/2] x86/tsc: Validate TSC_ADJUST after resume Thomas Gleixner
2016-12-13 13:22   ` Peter Zijlstra
2016-12-13 13:23     ` Thomas Gleixner
2016-12-15 10:52   ` [tip:x86/timers] " tip-bot for Thomas Gleixner
2016-12-13 13:14 ` [patch 2/2] x86/tsc: Force TSC_ADJUST register to value >= zero Thomas Gleixner
2016-12-13 13:43   ` Peter Zijlstra
2016-12-13 15:49     ` Thomas Gleixner
2016-12-15 10:53   ` [tip:x86/timers] " tip-bot for Thomas Gleixner
2016-12-16 11:46   ` [patch 2/2] " Thomas Gleixner
2016-12-16 11:52     ` Ingo Molnar
2016-12-16 11:53       ` Thomas Gleixner
2016-12-16 13:33     ` Thomas Gleixner
2016-12-13 16:34 ` [patch 0/2] tsc/adjust: Cure suspend/resume issues and prevent TSC deadline timer irq storm Roland Scheidegger
2016-12-13 16:46   ` Thomas Gleixner
2016-12-14  1:36     ` Roland Scheidegger
2016-12-14  7:31       ` Thomas Gleixner
2016-12-14 20:59         ` Thomas Gleixner
2016-12-14 21:40           ` Thomas Gleixner [this message]
2016-12-14 22:54             ` Roland Scheidegger
2016-12-15  9:31               ` Thomas Gleixner
2017-01-26 23:40                 ` Stanton, Kevin B

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=alpine.DEB.2.20.1612142225130.5283@nanos \
    --to=tglx@linutronix.de \
    --cc=allen_hung@dell.com \
    --cc=bp@alien8.de \
    --cc=bruce.schlobohm@intel.com \
    --cc=kevin.b.stanton@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=rscheidegger_lists@hispeed.ch \
    --cc=x86@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).