The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: "Lendacky, Thomas" <Thomas.Lendacky@amd.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"x86@kernel.org" <x86@kernel.org>, Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Namhyung Kim <namhyung@kernel.org>, Jiri Olsa <jolsa@redhat.com>,
	Jerry Hoemann <jerry.hoemann@hpe.com>
Subject: Re: [PATCH] perf/x86/amd: Change NMI latency mitigation to use a timestamp
Date: Fri, 2 Aug 2019 18:20:15 +0200	[thread overview]
Message-ID: <20190802162015.GA2349@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <925c3458-aeae-a44b-ddd5-40a1e173a307@amd.com>

On Fri, Aug 02, 2019 at 02:33:41PM +0000, Lendacky, Thomas wrote:
> On 8/1/19 4:59 PM, Thomas Gleixner wrote:
> > On Thu, 1 Aug 2019, Peter Zijlstra wrote:
> >> On Thu, Aug 01, 2019 at 11:34:23PM +0200, Thomas Gleixner wrote:
> >>> Avoid the whole NMI mess, make the PMC interrupt a proper vector in the
> >>> highest prio bucket and instead of using CLI/STI use CR8. That would have
> >>> the additional advantage that we could prevent perf "NMI" then occsionally :)
> >>
> >> Exactly, and not only the PMC, we can basically start giving out actual
> >> vectors on register_nmi_handler() and do away with all that shared line
> >> crap.
> >>
> >> And then the actual NMI line will be mostly empty again, and it can read
> >> its stupid slow reason port again.
> >>
> >> One complication though; IRET et al only do EFLAGS, not CR8, so that's
> >> going to be massive fun :-(
> 
> Talking to the hardware folks, they say setting CR8 is a serializing
> instruction and has to communicate out to the APIC, so it's better to
> use CLI/STI.

Bah; the Intel SDM states: "MOV CR* instructions, except for MOV CR8,
are serializing instructions", which had given me a little hope.

At the same time, all these chips still have the APIC TPR field too, so
much like how the TSC DEADLINE MSR is a hidden APIC write, so too is CR8
I suppose :-(

I'll still finish the patches I started, just to see what it would look
like.

Thomas mentioned combining this with software IRQ disable (like Power),
but at that point maybe full software priorities aren't too bad either.
We'll see.

  reply	other threads:[~2019-08-02 16:20 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-01 18:57 [PATCH] perf/x86/amd: Change NMI latency mitigation to use a timestamp Lendacky, Thomas
2019-08-01 21:16 ` Peter Zijlstra
2019-08-01 21:29   ` Lendacky, Thomas
2019-08-01 21:34     ` Thomas Gleixner
2019-08-01 21:48       ` Peter Zijlstra
2019-08-01 21:59         ` Thomas Gleixner
2019-08-02 14:33           ` Lendacky, Thomas
2019-08-02 16:20             ` Peter Zijlstra [this message]
2019-08-02 16:33               ` Peter Zijlstra
2019-08-08 20:33                 ` Jerry Hoemann
2019-09-13 19:52                   ` Jerry Hoemann

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=20190802162015.GA2349@hirez.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=Thomas.Lendacky@amd.com \
    --cc=acme@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=bp@alien8.de \
    --cc=jerry.hoemann@hpe.com \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=tglx@linutronix.de \
    --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