From: Sukadev Bhattiprolu <sukadev@linux•vnet.ibm.com>
To: Anshuman Khandual <khandual@linux•vnet.ibm.com>
Cc: linuxppc-dev@ozlabs•org, Paul Mackerras <paulus@samba•org>
Subject: Re: [PATCH 2/8] powerpc/perf: Rework disable logic in pmu_disable()
Date: Tue, 9 Jul 2013 17:15:23 -0700 [thread overview]
Message-ID: <20130710001523.GA24980@us.ibm.com> (raw)
In-Reply-To: <51C97D7F.4030405@linux.vnet.ibm.com>
Anshuman Khandual [khandual@linux•vnet.ibm.com] wrote:
| On 06/24/2013 04:58 PM, Michael Ellerman wrote:
| > In pmu_disable() we disable the PMU by setting the FC (Freeze Counters)
| > bit in MMCR0. In order to do this we have to read/modify/write MMCR0.
| >
| > It's possible that we read a value from MMCR0 which has PMAO (PMU Alert
| > Occurred) set. When we write that value back it will cause an interrupt
| > to occur. We will then end up in the PMU interrupt handler even though
| > we are supposed to have just disabled the PMU.
| >
|
| Is that possible ? First of all MMCR0[PMAO] could not be written by SW.
| Even if you try writing it, how its going to generate PMU interrupt ?
| HW sets this bit MMCR0[PMAO] after a PMU interrupt has already occurred
| not that if we set this, a PMU interrupt would be generated.
Looks like writing 1 MMCR0[PMAO] is allowed (to save interrupts across
partition swaps) and it does generate the interrupt.
|
| > We can avoid this by making sure we never write PMAO back. We should not
|
| Making sure that we dont write PMAO back is a good idea though.
|
| > lose interrupts because when the PMU is re-enabled the overflowed values
| > will cause another interrupt.
Is it enough to set the FC and clear the PMAO - or should we also clear the
PMAE in pmu_disable() (and set it back in pmu_enable()) ?
The PMU spec says "...Alert will occur when enabled condition or event exists
and Performance Monitor Alerts are enabled through MMCR0[PMAE] field"
The condition of overflowing counter will still exist and the PMAE is still
set. So, won't the PMU simply turn PMAO back on after we clear it ?
Or is it that PMAO is only set when counting is enabled but the interrupt is
generated even when counting is disabled ?
| >
|
| I doubt this theory.
|
| > We also reorder the clearing of SAMPLE_ENABLE so that is done after the
| > PMU is frozen. Otherwise there is a small window between the clearing of
| > SAMPLE_ENABLE and the setting of FC where we could take an interrupt and
| > incorrectly see SAMPLE_ENABLE not set. This would for example change the
| > logic in perf_read_regs().
| >
Good point.
next prev parent reply other threads:[~2013-07-10 0:15 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-24 11:28 [PATCH 1/8] powerpc/perf: Check that events only include valid bits on Power8 Michael Ellerman
2013-06-24 11:28 ` [PATCH 2/8] powerpc/perf: Rework disable logic in pmu_disable() Michael Ellerman
2013-06-25 11:22 ` Anshuman Khandual
2013-06-26 3:28 ` Michael Ellerman
2013-07-10 0:15 ` Sukadev Bhattiprolu [this message]
2013-07-10 2:12 ` Michael Ellerman
2013-06-24 11:28 ` [PATCH 3/8] powerpc/perf: Freeze PMC5/6 if we're not using them Michael Ellerman
2013-06-24 11:28 ` [PATCH 4/8] powerpc/perf: Use existing out label in power_pmu_enable() Michael Ellerman
2013-06-27 11:01 ` Anshuman Khandual
2013-06-24 11:28 ` [PATCH 5/8] powerpc/perf: Don't enable if we have zero events Michael Ellerman
2013-06-28 5:10 ` Anshuman Khandual
2013-06-24 11:28 ` [PATCH 6/8] powerpc/perf: Drop MMCRA from thread_struct Michael Ellerman
2013-06-24 11:28 ` [PATCH 7/8] powerpc/perf: Core EBB support for 64-bit book3s Michael Ellerman
2013-06-26 8:38 ` Anshuman Khandual
2013-06-27 11:52 ` Michael Ellerman
2013-06-24 11:28 ` [PATCH 8/8] powerpc/perf: Add power8 EBB support Michael Ellerman
2013-06-26 9:58 ` Anshuman Khandual
2013-06-27 11:52 ` Michael Ellerman
2013-06-28 4:15 ` Anshuman Khandual
2013-07-04 18:58 ` Adhemerval Zanella
2013-07-05 2:54 ` Michael Ellerman
2013-07-05 17:57 ` Adhemerval Zanella
2013-06-25 10:55 ` [PATCH 1/8] powerpc/perf: Check that events only include valid bits on Power8 Anshuman Khandual
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=20130710001523.GA24980@us.ibm.com \
--to=sukadev@linux$(echo .)vnet.ibm.com \
--cc=khandual@linux$(echo .)vnet.ibm.com \
--cc=linuxppc-dev@ozlabs$(echo .)org \
--cc=paulus@samba$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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