From: Thomas Gleixner <tglx@linutronix.de>
To: Stephane Eranian <eranian@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Vince Weaver <vincent.weaver@maine.edu>,
Andi Kleen <ak@linux.intel.com>,
"Liang, Kan" <kan.liang@intel.com>,
"mingo@redhat.com" <mingo@redhat.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"alexander.shishkin@linux.intel.com"
<alexander.shishkin@linux.intel.com>,
"acme@redhat.com" <acme@redhat.com>,
"jolsa@redhat.com" <jolsa@redhat.com>,
"torvalds@linux-foundation.org" <torvalds@linux-foundation.org>
Subject: Re: [PATCH 1/2] perf/x86/intel: enable CPU ref_cycles for GP counter
Date: Tue, 30 May 2017 18:55:49 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.20.1705301843420.1950@nanos> (raw)
In-Reply-To: <CABPqkBSSr=+GdprEapSEjUN+3+O+ko_0RsJNCKSSpbHz+ULORQ@mail.gmail.com>
On Tue, 30 May 2017, Stephane Eranian wrote:
> On Tue, May 30, 2017 at 2:25 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> > On Sun, May 28, 2017 at 01:31:09PM -0700, Stephane Eranian wrote:
> >> Ultimately, I would like to see the watchdog move out of the PMU. That
> >> is the only sensible solution.
> >> You just need a resource able to interrupt on NMI or you handle
> >> interrupt masking in software as has
> >> been proposed on LKML.
> >
> > So even if we do the soft masking, we still need to deal with regions
> > where the interrupts are disabled. Once an interrupt hits the soft mask
> > we still hardware mask.
> >
> What I was thinking is that you never hardware mask, software always
> catches the hw interrupts and keeps them pending or deliver them
> depending on sw mask.
That does not work.
1) You still need some sections where you must have hardware masking.
2) Software cannot keep them pending in hardware other than disabling
interrupts at the CPU level and returning to the interrupted sections
without issuing EOI. Reenabling them at the CPU level will reinject
them in hardware.
If we actually want send the EOI and keep a irq pending mask in
software then we cannot do that quick in the low level entry code. We
need to go up into the generic interrupt code, take a bunch of locks
which expect interrupts disable and figure out what to do with the
interrupt.
That's required because the low level entry code has no idea how to
deal with that interrupt, i.e. which physical interrupt controller to
talk to. Due to our stacked irq chips we can end up with rather
complex call chains there.
Of course this involves locking which will deadlock if such a lock has
been taken at some other place with interrupts just soft disabled.
Thanks,
tglx
next prev parent reply other threads:[~2017-05-30 16:56 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-19 17:06 kan.liang
2017-05-19 17:06 ` [PATCH 2/2] perf/x86/intel, watchdog: Switch NMI watchdog to ref cycles on x86 kan.liang
2017-05-22 12:03 ` Peter Zijlstra
2017-05-22 12:04 ` Peter Zijlstra
2017-05-22 16:58 ` Liang, Kan
2017-05-22 19:24 ` Peter Zijlstra
2017-05-22 18:20 ` Stephane Eranian
2017-05-22 20:01 ` Andi Kleen
2017-05-22 8:30 ` [PATCH 1/2] perf/x86/intel: enable CPU ref_cycles for GP counter Peter Zijlstra
2017-05-22 18:15 ` Stephane Eranian
2017-05-22 9:19 ` Peter Zijlstra
2017-05-22 12:22 ` Peter Zijlstra
2017-05-22 16:59 ` Liang, Kan
2017-05-22 16:55 ` Liang, Kan
2017-05-22 19:23 ` Peter Zijlstra
2017-05-22 19:28 ` Stephane Eranian
2017-05-22 21:51 ` Liang, Kan
2017-05-23 6:39 ` Peter Zijlstra
2017-05-23 6:42 ` Stephane Eranian
2017-05-24 15:45 ` Andi Kleen
2017-05-24 16:01 ` Vince Weaver
2017-05-24 16:55 ` Andi Kleen
2017-05-28 20:31 ` Stephane Eranian
2017-05-30 9:25 ` Peter Zijlstra
2017-05-30 13:51 ` Andi Kleen
2017-05-30 16:28 ` Peter Zijlstra
2017-05-30 16:41 ` Stephane Eranian
2017-05-30 17:22 ` Andi Kleen
2017-05-30 17:40 ` Peter Zijlstra
2017-05-30 17:51 ` Andi Kleen
2017-05-30 18:59 ` Peter Zijlstra
2017-05-30 19:40 ` Andi Kleen
2017-05-30 16:39 ` Stephane Eranian
2017-05-30 16:55 ` Thomas Gleixner [this message]
2017-05-30 17:25 ` Peter Zijlstra
2017-05-31 20:57 ` Vince Weaver
2017-05-28 2:56 ` kbuild test robot
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.1705301843420.1950@nanos \
--to=tglx@linutronix.de \
--cc=acme@redhat.com \
--cc=ak@linux.intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=eranian@google.com \
--cc=jolsa@redhat.com \
--cc=kan.liang@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=torvalds@linux-foundation.org \
--cc=vincent.weaver@maine.edu \
/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
all inboxes | Powered by JetHome®