All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephane Eranian <eranian@google.com>
To: Michael Neuling <mikey@neuling.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	"ak@linux.intel.com" <ak@linux.intel.com>,
	Michael Ellerman <michael@ellerman.id.au>,
	"benh@kernel.crashing.org" <benh@kernel.crashing.org>,
	Linux PPC dev <linuxppc-dev@ozlabs.org>
Subject: Re: [PATCH 3/3] perf, x86, lbr: Demand proper privileges for PERF_SAMPLE_BRANCH_KERNEL
Date: Sat, 18 May 2013 00:59:11 +0200	[thread overview]
Message-ID: <CABPqkBSX+BVHz5NnQnaa7tmU6D5DdpS21XWxVPQ_gaX-OOpZHA@mail.gmail.com> (raw)
In-Reply-To: <30065.1368828892@ale.ozlabs.ibm.com>

On Sat, May 18, 2013 at 12:14 AM, Michael Neuling <mikey@neuling.org> wrote:
> Stephane Eranian <eranian@google.com> wrote:
>
>> On Fri, May 17, 2013 at 1:39 PM, Peter Zijlstra <peterz@infradead.org> wrote:
>> > On Fri, May 17, 2013 at 09:32:08PM +1000, Michael Neuling wrote:
>> >> Peter Zijlstra <peterz@infradead.org> wrote:
>> >
>> >> > Wouldn't it be mostly conditional branches that are the primary control flow
>> >> > and can get predicted wrong? I mean, I'm sure someone will miss-predict an
>> >> > unconditional branch but its not like we care about people with such
>> >> > afflictions do we?
>> >>
>> >> You could mispredict the target address of a computed goto.  You'd know
>> >> it was taken but not know target address until later in the pipeline.
>> >
>> > Oh right, computed targets could indeed be mis predicted. I was more thinking
>> > about jumps with immediate values.
>> >
>> >> On this, the POWER8 branch history buffer tells us two things about the
>> >> prediction status.
>> >>   1) if the branch was predicted taken/not taken correctly
>> >>   2) if the target address was predicted correctly or not (for computed
>> >>      gotos only)
>> >> So we'd actually like more prediction bits too :-D
>> >
>> > So if I understand this right, 1) maps to the predicted flags we have; 2)
>> > would be new stuff?
>> >
>> > We don't really have anything like that on x86, but I suppose if you make the
>> > thing optional and present a 'useful' use-case implemented in userspace code
>> > we could take it :-)
>> >
>> >> > Anyway, since PPC people thought it worth baking into hardware,
>> >> > presumably they have a compelling use case. Mikey could you see if you
>> >> > can retrieve that from someone in the know? It might be interesting.
>> >>
>> >> I don't think we can mispredict a non-conditional non-computed but I'll
>> >> have to check with the HW folks.
>> >
>> > I was mostly wondering about the use-case for the conditional filter. Stephane
>> > didn't think it useful, clearly your hardware guys thought different :-)
>>
>> From my experience talking with compiler people, they care about ALL
>> the branches and not the conditional so much. They use LBR to do basic
>> block profiling.
>
> OK.  I don't have a good handle on what's useful for compilers or JITs
> right now.  I'm just plumbing through what's possible.
>
I understand. It is okay to extend the interface.

WARNING: multiple messages have this Message-ID (diff)
From: Stephane Eranian <eranian@google.com>
To: Michael Neuling <mikey@neuling.org>
Cc: "ak@linux.intel.com" <ak@linux.intel.com>,
	Peter Zijlstra <peterz@infradead.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Linux PPC dev <linuxppc-dev@ozlabs.org>,
	Ingo Molnar <mingo@kernel.org>
Subject: Re: [PATCH 3/3] perf, x86, lbr: Demand proper privileges for PERF_SAMPLE_BRANCH_KERNEL
Date: Sat, 18 May 2013 00:59:11 +0200	[thread overview]
Message-ID: <CABPqkBSX+BVHz5NnQnaa7tmU6D5DdpS21XWxVPQ_gaX-OOpZHA@mail.gmail.com> (raw)
In-Reply-To: <30065.1368828892@ale.ozlabs.ibm.com>

On Sat, May 18, 2013 at 12:14 AM, Michael Neuling <mikey@neuling.org> wrote:
> Stephane Eranian <eranian@google.com> wrote:
>
>> On Fri, May 17, 2013 at 1:39 PM, Peter Zijlstra <peterz@infradead.org> wrote:
>> > On Fri, May 17, 2013 at 09:32:08PM +1000, Michael Neuling wrote:
>> >> Peter Zijlstra <peterz@infradead.org> wrote:
>> >
>> >> > Wouldn't it be mostly conditional branches that are the primary control flow
>> >> > and can get predicted wrong? I mean, I'm sure someone will miss-predict an
>> >> > unconditional branch but its not like we care about people with such
>> >> > afflictions do we?
>> >>
>> >> You could mispredict the target address of a computed goto.  You'd know
>> >> it was taken but not know target address until later in the pipeline.
>> >
>> > Oh right, computed targets could indeed be mis predicted. I was more thinking
>> > about jumps with immediate values.
>> >
>> >> On this, the POWER8 branch history buffer tells us two things about the
>> >> prediction status.
>> >>   1) if the branch was predicted taken/not taken correctly
>> >>   2) if the target address was predicted correctly or not (for computed
>> >>      gotos only)
>> >> So we'd actually like more prediction bits too :-D
>> >
>> > So if I understand this right, 1) maps to the predicted flags we have; 2)
>> > would be new stuff?
>> >
>> > We don't really have anything like that on x86, but I suppose if you make the
>> > thing optional and present a 'useful' use-case implemented in userspace code
>> > we could take it :-)
>> >
>> >> > Anyway, since PPC people thought it worth baking into hardware,
>> >> > presumably they have a compelling use case. Mikey could you see if you
>> >> > can retrieve that from someone in the know? It might be interesting.
>> >>
>> >> I don't think we can mispredict a non-conditional non-computed but I'll
>> >> have to check with the HW folks.
>> >
>> > I was mostly wondering about the use-case for the conditional filter. Stephane
>> > didn't think it useful, clearly your hardware guys thought different :-)
>>
>> From my experience talking with compiler people, they care about ALL
>> the branches and not the conditional so much. They use LBR to do basic
>> block profiling.
>
> OK.  I don't have a good handle on what's useful for compilers or JITs
> right now.  I'm just plumbing through what's possible.
>
I understand. It is okay to extend the interface.

  reply	other threads:[~2013-05-17 22:59 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-03 12:11 [PATCH 0/3] Various perf patches Peter Zijlstra
2013-05-03 12:11 ` [PATCH 1/3] perf, x86: Blacklist all MEM_*_RETIRED events for IVB Peter Zijlstra
2013-05-03 14:35   ` Andi Kleen
2013-05-03 17:00     ` Peter Zijlstra
2013-05-15 14:20       ` Stephane Eranian
2013-05-15 16:51         ` Peter Zijlstra
2013-05-16 15:42           ` Stephane Eranian
2013-05-16 16:07             ` Andi Kleen
2013-05-16 16:26               ` Stephane Eranian
2013-05-04  8:20   ` [tip:perf/urgent] perf/x86: Blacklist all MEM_*_RETIRED events for Ivy Bridge tip-bot for Peter Zijlstra
2013-05-03 12:11 ` [PATCH 2/3] perf, x86, lbr: Fix LBR filter Peter Zijlstra
2013-05-03 14:34   ` Andi Kleen
2013-05-04  6:34     ` Ingo Molnar
2013-05-04  8:21   ` [tip:perf/urgent] perf/x86/intel/lbr: " tip-bot for Peter Zijlstra
2013-05-03 12:11 ` [PATCH 3/3] perf, x86, lbr: Demand proper privileges for PERF_SAMPLE_BRANCH_KERNEL Peter Zijlstra
2013-05-03 14:41   ` Andi Kleen
2013-05-04  8:22   ` [tip:perf/urgent] perf/x86/intel/lbr: " tip-bot for Peter Zijlstra
2013-05-04 11:19     ` Borislav Petkov
2013-05-05  9:05       ` Ingo Molnar
2013-05-06  8:07       ` Peter Zijlstra
2013-05-06  9:42         ` Ingo Molnar
2013-05-15 13:37   ` [PATCH 3/3] perf, x86, lbr: " Stephane Eranian
2013-05-15 14:30     ` Peter Zijlstra
2013-05-16  9:09     ` Peter Zijlstra
2013-05-16  9:17       ` Peter Zijlstra
2013-05-16 10:09       ` Michael Neuling
2013-05-16 10:09         ` Michael Neuling
2013-05-16 10:15       ` Michael Neuling
2013-05-16 10:15         ` Michael Neuling
2013-05-16 11:16         ` Peter Zijlstra
2013-05-16 11:16           ` Peter Zijlstra
2013-05-16 15:36           ` Stephane Eranian
2013-05-16 15:36             ` Stephane Eranian
2013-05-17 11:12             ` Peter Zijlstra
2013-05-17 11:12               ` Peter Zijlstra
2013-05-17 11:32               ` Michael Neuling
2013-05-17 11:32                 ` Michael Neuling
2013-05-17 11:39                 ` Peter Zijlstra
2013-05-17 11:39                   ` Peter Zijlstra
2013-05-17 21:39                   ` Stephane Eranian
2013-05-17 21:39                     ` Stephane Eranian
2013-05-17 22:14                     ` Michael Neuling
2013-05-17 22:14                       ` Michael Neuling
2013-05-17 22:59                       ` Stephane Eranian [this message]
2013-05-17 22:59                         ` Stephane Eranian
2013-05-21  5:41               ` Michael Neuling
2013-05-21  5:41                 ` Michael Neuling
2013-05-21  8:50                 ` Peter Zijlstra
2013-05-21  8:50                   ` Peter Zijlstra
2013-05-21 13:46                   ` Stephane Eranian
2013-05-21 13:46                     ` Stephane Eranian
2013-05-21 13:55         ` Stephane Eranian
2013-05-21 13:55           ` Stephane Eranian
2013-05-22  6:43           ` Anshuman Khandual
2013-05-22 12:23             ` Stephane Eranian
2013-05-22 14:51               ` 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=CABPqkBSX+BVHz5NnQnaa7tmU6D5DdpS21XWxVPQ_gaX-OOpZHA@mail.gmail.com \
    --to=eranian@google.com \
    --cc=ak@linux.intel.com \
    --cc=benh@kernel.crashing.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=michael@ellerman.id.au \
    --cc=mikey@neuling.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.