linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Michael Ellerman <michael@ellerman.id.au>
To: Anshuman Khandual <khandual@linux.vnet.ibm.com>
Cc: linuxppc-dev@ozlabs.org, mikey@neuling.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] powerpc, perf: Ignore separate BHRB privilege state filter request
Date: Wed, 22 May 2013 17:14:15 +1000	[thread overview]
Message-ID: <1369206855.12874.9.camel@concordia> (raw)
In-Reply-To: <1369201667-9048-2-git-send-email-khandual@linux.vnet.ibm.com>

On Wed, 2013-05-22 at 11:17 +0530, Anshuman Khandual wrote:
> Completely ignore BHRB privilege state filter request as we are
> already configuring MMCRA register with privilege state filtering
> attribute for the accompanying PMU event. This would help achieve
> cleaner user space interaction for BHRB.

Your description from patch 0 should be here.


> diff --git a/arch/powerpc/perf/power8-pmu.c b/arch/powerpc/perf/power8-pmu.c
> index f7d1c4f..8ed323d 100644
> --- a/arch/powerpc/perf/power8-pmu.c
> +++ b/arch/powerpc/perf/power8-pmu.c
> @@ -525,16 +525,17 @@ static u64 power8_bhrb_filter_map(u64 branch_sample_type)
>  	u64 pmu_bhrb_filter = 0;
>  	u64 br_privilege = branch_sample_type & ONLY_PLM;
>  
> -	/* BHRB and regular PMU events share the same prvillege state
> +	/* BHRB and regular PMU events share the same prvilege state

Please spell "privilege" correctly.

>  	 * filter configuration. BHRB is always recorded along with a
> -	 * regular PMU event. So privilege state filter criteria for BHRB
> -	 * and the companion PMU events has to be the same. As a default
> -	 * "perf record" tool sets all privillege bits ON when no filter
> -	 * criteria is provided in the command line. So as along as all
> -	 * privillege bits are ON or they are OFF, we are good to go.
> +	 * regular PMU event. So privilege state filter criteria for
> +	 * the BHRB and the companion PMU events has to be the same.
> +	 * Separate BHRB privillege state filter requests would be
> +	 * ignored.
>  	 */

This comment doesn't make sense to me with the updated code.

It still says "privilege state filter criteria for the BHRB and the
companion PMU events has to be the same".

But they don't, right?

What it should say is "we ignore the privilege bits in the branch sample
type because they are handled by the underlying PMC configuration" - or
something like that.

> -	if ((br_privilege != 7) && (br_privilege != 0))
> -		return -1;
> +
> +	if (br_privilege)
> +		pr_info("BHRB privilege state filter request %llx ignored\n",
> +								br_privilege);

Don't do that. Ignoring the br_privilege is either the right thing to do
in which case we do it and print nothing, or it doesn't make sense and
we reject it.

cheers

  reply	other threads:[~2013-05-22  7:14 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-22  5:47 [PATCH 0/2] Improvement and fixes for BHRB Anshuman Khandual
2013-05-22  5:47 ` [PATCH 1/2] powerpc, perf: Ignore separate BHRB privilege state filter request Anshuman Khandual
2013-05-22  7:14   ` Michael Ellerman [this message]
2013-05-22  8:59     ` Anshuman Khandual
2013-05-27 10:02       ` Anshuman Khandual
2013-05-27 23:30         ` Michael Neuling
2013-05-22  5:47 ` [PATCH 2/2] powerpc, perf: BHRB filter configuration should follow the task 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=1369206855.12874.9.camel@concordia \
    --to=michael@ellerman.id.au \
    --cc=khandual@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=mikey@neuling.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).