Re: [RFC PATCH 0/3]perf/core: extend perf_reg and perf_sample_regs_intr

[Michael Ellerman]

On Fri, 2015-11-06 at 11:25 +0100, Peter Zijlstra wrote:

> On Fri, Nov 06, 2015 at 09:04:00PM +1100, Michael Ellerman wrote:

> > It's a perrenial request from our hardware PMU folks to be able to see the 
> > raw
> > values of the PMU registers.
> > 
> > I think partly it's so that they can verify that perf is doing what they 
> > want,
> > and some of it is that they're interested in some of the more obscure info 
> > that
> > isn't plumbed out through other perf interfaces.
> > 
> > We've used various internal hacks over the years to keep them happy. This 
> > is an
> > attempt to use a somewhat standard mechanism.
> > 
> > It would also be helpful for those of us working on the perf hardware 
> > backends,
> > to be able to verify that we're programming things correctly, without 
> > resorting
> > to debug printks etc.
> > 
> > Basically we want to sample regs at the time of the perf interrupt, so we
> > though PERF_SAMPLE_REGS_INTR made senes :)
> > 
> > But if you think this is the wrong mechanism within perf, then please let us
> > know.
> > 
> > I know perf's mission is to abstract as much of the arcane hardware details
> > into a generic interface and make PMUs actually useful for normal folks, 
> > and we
> > are committed to that, but it would also be useful to be able to get the raw
> > values for a different type of user.
> > 
> > Maddy's patch only exports PMC1-6 and MMCR0/1. I think we also need to 
> > export
> > some others, in particular MMCRA has a lot of stuff in it, half of which is 
> > not
> > even architected. So that would have to be exported as "POWER8_MMCRA". And 
> > then
> > there's the SIAR/SDAR/SIER which contain a bunch of info on sampled
> > instructions that is not currently plumbed out.
> 
> OK, no objections then. But this is useful information and should be
> included in the patch set.

Thanks, yeah definitely needs more explanation in the patch set.

cheers

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 0/3]perf/core: extend perf_reg and perf_sample_regs_intr

[Michael Ellerman]

On Fri, 2015-11-06 at 11:25 +0100, Peter Zijlstra wrote:

> On Fri, Nov 06, 2015 at 09:04:00PM +1100, Michael Ellerman wrote:

> > It's a perrenial request from our hardware PMU folks to be able to see the 
> > raw
> > values of the PMU registers.
> > 
> > I think partly it's so that they can verify that perf is doing what they 
> > want,
> > and some of it is that they're interested in some of the more obscure info 
> > that
> > isn't plumbed out through other perf interfaces.
> > 
> > We've used various internal hacks over the years to keep them happy. This 
> > is an
> > attempt to use a somewhat standard mechanism.
> > 
> > It would also be helpful for those of us working on the perf hardware 
> > backends,
> > to be able to verify that we're programming things correctly, without 
> > resorting
> > to debug printks etc.
> > 
> > Basically we want to sample regs at the time of the perf interrupt, so we
> > though PERF_SAMPLE_REGS_INTR made senes :)
> > 
> > But if you think this is the wrong mechanism within perf, then please let us
> > know.
> > 
> > I know perf's mission is to abstract as much of the arcane hardware details
> > into a generic interface and make PMUs actually useful for normal folks, 
> > and we
> > are committed to that, but it would also be useful to be able to get the raw
> > values for a different type of user.
> > 
> > Maddy's patch only exports PMC1-6 and MMCR0/1. I think we also need to 
> > export
> > some others, in particular MMCRA has a lot of stuff in it, half of which is 
> > not
> > even architected. So that would have to be exported as "POWER8_MMCRA". And 
> > then
> > there's the SIAR/SDAR/SIER which contain a bunch of info on sampled
> > instructions that is not currently plumbed out.
> 
> OK, no objections then. But this is useful information and should be
> included in the patch set.

Thanks, yeah definitely needs more explanation in the patch set.

cheers

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 0/3]perf/core: extend perf_reg and perf_sample_regs_intr

[Madhavan Srinivasan]

On Friday 06 November 2015 03:55 PM, Peter Zijlstra wrote:
> On Fri, Nov 06, 2015 at 09:04:00PM +1100, Michael Ellerman wrote:
>> It's a perrenial request from our hardware PMU folks to be able to see the 
>> raw
>> values of the PMU registers.
>>
>> I think partly it's so that they can verify that perf is doing what they 
>> want,
>> and some of it is that they're interested in some of the more obscure info 
>> that
>> isn't plumbed out through other perf interfaces.
>>
>> We've used various internal hacks over the years to keep them happy. This is 
>> an
>> attempt to use a somewhat standard mechanism.
>>
>> It would also be helpful for those of us working on the perf hardware 
>> backends,
>> to be able to verify that we're programming things correctly, without 
>> resorting
>> to debug printks etc.
>>
>> Basically we want to sample regs at the time of the perf interrupt, so we
>> though PERF_SAMPLE_REGS_INTR made senes :)
>>
>> But if you think this is the wrong mechanism within perf, then please let us
>> know.
>>
>> I know perf's mission is to abstract as much of the arcane hardware details
>> into a generic interface and make PMUs actually useful for normal folks, and 
>> we
>> are committed to that, but it would also be useful to be able to get the raw
>> values for a different type of user.
>>
>> Maddy's patch only exports PMC1-6 and MMCR0/1. I think we also need to export
>> some others, in particular MMCRA has a lot of stuff in it, half of which is 
>> not
>> even architected. So that would have to be exported as "POWER8_MMCRA". And 
>> then
>> there's the SIAR/SDAR/SIER which contain a bunch of info on sampled
>> instructions that is not currently plumbed out.
> OK, no objections then. But this is useful information and should be
> included in the patch set.
>

Sure. Will add the information in the next version.

Maddy


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 0/3]perf/core: extend perf_reg and perf_sample_regs_intr

[Madhavan Srinivasan]

On Friday 06 November 2015 03:34 PM, Michael Ellerman wrote:
> On Fri, 2015-11-06 at 10:24 +0100, Peter Zijlstra wrote:
>> On Fri, Nov 06, 2015 at 12:57:17PM +0530, Madhavan Srinivasan wrote:
>>> On Thursday 05 November 2015 06:37 PM, Peter Zijlstra wrote:
 On Thu, Nov 05, 2015 at 02:16:15AM +0530, Madhavan Srinivasan wrote:
> Second patch updates struct arch_misc_reg for arch/powerpc with pmu 
> registers
> and adds offsetof macro for the same. It extends perf_reg_value()
> to use reg idx to decide on struct to return value from.
 Why; what's in those regs?
>>> Was out and did not have access to mail, so missed to respond in time.
>>>
>>> In current implementation of patch 2, have added 
>>> few pmu control/status and counter registers,
>>> which give additional information about the PMU context
>>> for the sample.
>> Yes, I saw that, you still haven't answered the question though. What is
>> in those regs? Why is exposing that information like this the best
>> option.
> It's a perrenial request from our hardware PMU folks to be able to see the raw
> values of the PMU registers.
>
> I think partly it's so that they can verify that perf is doing what they want,
> and some of it is that they're interested in some of the more obscure info 
> that
> isn't plumbed out through other perf interfaces.
>
> We've used various internal hacks over the years to keep them happy. This is 
> an
> attempt to use a somewhat standard mechanism.
>
> It would also be helpful for those of us working on the perf hardware 
> backends,
> to be able to verify that we're programming things correctly, without 
> resorting
> to debug printks etc.
>
> Basically we want to sample regs at the time of the perf interrupt, so we
> though PERF_SAMPLE_REGS_INTR made senes :)
>
> But if you think this is the wrong mechanism within perf, then please let us
> know.
>
> I know perf's mission is to abstract as much of the arcane hardware details
> into a generic interface and make PMUs actually useful for normal folks, and 
> we
> are committed to that, but it would also be useful to be able to get the raw
> values for a different type of user.
>
> Maddy's patch only exports PMC1-6 and MMCR0/1. I think we also need to export
> some others, in particular MMCRA has a lot of stuff in it, half of which is 
> not
> even architected. So that would have to be exported as "POWER8_MMCRA". And 
> then
> there's the SIAR/SDAR/SIER which contain a bunch of info on sampled
> instructions that is not currently plumbed out.

Sure. I will rework the patch to include the other regs also.

Maddy

>
> cheers
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 0/3]perf/core: extend perf_reg and perf_sample_regs_intr

[Peter Zijlstra]

On Fri, Nov 06, 2015 at 09:04:00PM +1100, Michael Ellerman wrote:
> It's a perrenial request from our hardware PMU folks to be able to see the raw
> values of the PMU registers.
> 
> I think partly it's so that they can verify that perf is doing what they want,
> and some of it is that they're interested in some of the more obscure info 
> that
> isn't plumbed out through other perf interfaces.
> 
> We've used various internal hacks over the years to keep them happy. This is 
> an
> attempt to use a somewhat standard mechanism.
> 
> It would also be helpful for those of us working on the perf hardware 
> backends,
> to be able to verify that we're programming things correctly, without 
> resorting
> to debug printks etc.
> 
> Basically we want to sample regs at the time of the perf interrupt, so we
> though PERF_SAMPLE_REGS_INTR made senes :)
> 
> But if you think this is the wrong mechanism within perf, then please let us
> know.
> 
> I know perf's mission is to abstract as much of the arcane hardware details
> into a generic interface and make PMUs actually useful for normal folks, and 
> we
> are committed to that, but it would also be useful to be able to get the raw
> values for a different type of user.
> 
> Maddy's patch only exports PMC1-6 and MMCR0/1. I think we also need to export
> some others, in particular MMCRA has a lot of stuff in it, half of which is 
> not
> even architected. So that would have to be exported as "POWER8_MMCRA". And 
> then
> there's the SIAR/SDAR/SIER which contain a bunch of info on sampled
> instructions that is not currently plumbed out.

OK, no objections then. But this is useful information and should be
included in the patch set.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 0/3]perf/core: extend perf_reg and perf_sample_regs_intr

[Michael Ellerman]

On Fri, 2015-11-06 at 10:24 +0100, Peter Zijlstra wrote:
> On Fri, Nov 06, 2015 at 12:57:17PM +0530, Madhavan Srinivasan wrote:
> > On Thursday 05 November 2015 06:37 PM, Peter Zijlstra wrote:
> > > On Thu, Nov 05, 2015 at 02:16:15AM +0530, Madhavan Srinivasan wrote:
> > > > Second patch updates struct arch_misc_reg for arch/powerpc with pmu 
> > > > registers
> > > > and adds offsetof macro for the same. It extends perf_reg_value()
> > > > to use reg idx to decide on struct to return value from.
> > > Why; what's in those regs?
> > 
> > Was out and did not have access to mail, so missed to respond in time.
> > 
> > In current implementation of patch 2, have added 
> > few pmu control/status and counter registers,
> > which give additional information about the PMU context
> > for the sample.
> 
> Yes, I saw that, you still haven't answered the question though. What is
> in those regs? Why is exposing that information like this the best
> option.

It's a perrenial request from our hardware PMU folks to be able to see the raw
values of the PMU registers.

I think partly it's so that they can verify that perf is doing what they want,
and some of it is that they're interested in some of the more obscure info that
isn't plumbed out through other perf interfaces.

We've used various internal hacks over the years to keep them happy. This is an
attempt to use a somewhat standard mechanism.

It would also be helpful for those of us working on the perf hardware backends,
to be able to verify that we're programming things correctly, without resorting
to debug printks etc.

Basically we want to sample regs at the time of the perf interrupt, so we
though PERF_SAMPLE_REGS_INTR made senes :)

But if you think this is the wrong mechanism within perf, then please let us
know.

I know perf's mission is to abstract as much of the arcane hardware details
into a generic interface and make PMUs actually useful for normal folks, and we
are committed to that, but it would also be useful to be able to get the raw
values for a different type of user.

Maddy's patch only exports PMC1-6 and MMCR0/1. I think we also need to export
some others, in particular MMCRA has a lot of stuff in it, half of which is not
even architected. So that would have to be exported as "POWER8_MMCRA". And then
there's the SIAR/SDAR/SIER which contain a bunch of info on sampled
instructions that is not currently plumbed out.

cheers

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 0/3]perf/core: extend perf_reg and perf_sample_regs_intr

[Michael Ellerman]

On Fri, 2015-11-06 at 13:17 +0530, Madhavan Srinivasan wrote:
> On Friday 06 November 2015 08:28 AM, Sukadev Bhattiprolu wrote:
> > Peter Zijlstra [pet...@infradead.org] wrote:
> > > On Thu, Nov 05, 2015 at 02:16:15AM +0530, Madhavan Srinivasan wrote:
> > > > Second patch updates struct arch_misc_reg for arch/powerpc with pmu 
> > > > registers
> > > > and adds offsetof macro for the same. It extends perf_reg_value()
> > > > to use reg idx to decide on struct to return value from.
> > > 
> > > Why; what's in those regs?
> > 
> > Those are PMU control registers/counters (in Patch 2) that are of
> > interest only in the context of a PMU interrupt and not relevant
> > to ptrace itself.
> 
> Yes. Thats right.

> > Could we add those registers to 'struct pt_regs' anyway?
> 
> I would prefer not to. Since as you mentioned, these are
> not relevant to ptrace. Currently patch 2, adds only few
> pmu registers, but would like to include more.

You can't just add them to pt_regs, it's part of the userspace ABI.

We could define a kernel internal version of pt_regs, but I don't think we want
to for this.

If we did that would bloat pt_regs for all users in the kernel, when we really
only want these regs for perf.

cheers

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 0/3]perf/core: extend perf_reg and perf_sample_regs_intr

[Peter Zijlstra]

On Fri, Nov 06, 2015 at 12:57:17PM +0530, Madhavan Srinivasan wrote:
> 
> 
> On Thursday 05 November 2015 06:37 PM, Peter Zijlstra wrote:
> > On Thu, Nov 05, 2015 at 02:16:15AM +0530, Madhavan Srinivasan wrote:
> >> Second patch updates struct arch_misc_reg for arch/powerpc with pmu 
> >> registers
> >> and adds offsetof macro for the same. It extends perf_reg_value()
> >> to use reg idx to decide on struct to return value from.
> > Why; what's in those regs?
> 
> Was out and did not have access to mail, so missed to respond in time.
> 
> In current implementation of patch 2, have added 
> few pmu control/status and counter registers,
> which give additional information about the PMU context
> for the sample.

Yes, I saw that, you still haven't answered the question though. What is
in those regs? Why is exposing that information like this the best
option.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 0/3]perf/core: extend perf_reg and perf_sample_regs_intr

[Madhavan Srinivasan]

On Friday 06 November 2015 03:34 PM, Michael Ellerman wrote:
> On Fri, 2015-11-06 at 10:24 +0100, Peter Zijlstra wrote:
>> On Fri, Nov 06, 2015 at 12:57:17PM +0530, Madhavan Srinivasan wrote:
>>> On Thursday 05 November 2015 06:37 PM, Peter Zijlstra wrote:
 On Thu, Nov 05, 2015 at 02:16:15AM +0530, Madhavan Srinivasan wrote:
> Second patch updates struct arch_misc_reg for arch/powerpc with pmu 
> registers
> and adds offsetof macro for the same. It extends perf_reg_value()
> to use reg idx to decide on struct to return value from.
 Why; what's in those regs?
>>> Was out and did not have access to mail, so missed to respond in time.
>>>
>>> In current implementation of patch 2, have added 
>>> few pmu control/status and counter registers,
>>> which give additional information about the PMU context
>>> for the sample.
>> Yes, I saw that, you still haven't answered the question though. What is
>> in those regs? Why is exposing that information like this the best
>> option.
> It's a perrenial request from our hardware PMU folks to be able to see the raw
> values of the PMU registers.
>
> I think partly it's so that they can verify that perf is doing what they want,
> and some of it is that they're interested in some of the more obscure info 
> that
> isn't plumbed out through other perf interfaces.
>
> We've used various internal hacks over the years to keep them happy. This is 
> an
> attempt to use a somewhat standard mechanism.
>
> It would also be helpful for those of us working on the perf hardware 
> backends,
> to be able to verify that we're programming things correctly, without 
> resorting
> to debug printks etc.
>
> Basically we want to sample regs at the time of the perf interrupt, so we
> though PERF_SAMPLE_REGS_INTR made senes :)
>
> But if you think this is the wrong mechanism within perf, then please let us
> know.
>
> I know perf's mission is to abstract as much of the arcane hardware details
> into a generic interface and make PMUs actually useful for normal folks, and 
> we
> are committed to that, but it would also be useful to be able to get the raw
> values for a different type of user.
>
> Maddy's patch only exports PMC1-6 and MMCR0/1. I think we also need to export
> some others, in particular MMCRA has a lot of stuff in it, half of which is 
> not
> even architected. So that would have to be exported as "POWER8_MMCRA". And 
> then
> there's the SIAR/SDAR/SIER which contain a bunch of info on sampled
> instructions that is not currently plumbed out.

Sure. I will rework the patch to include the other regs also.

Maddy

>
> cheers
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 0/3]perf/core: extend perf_reg and perf_sample_regs_intr

[Madhavan Srinivasan]

On Friday 06 November 2015 03:55 PM, Peter Zijlstra wrote:
> On Fri, Nov 06, 2015 at 09:04:00PM +1100, Michael Ellerman wrote:
>> It's a perrenial request from our hardware PMU folks to be able to see the 
>> raw
>> values of the PMU registers.
>>
>> I think partly it's so that they can verify that perf is doing what they 
>> want,
>> and some of it is that they're interested in some of the more obscure info 
>> that
>> isn't plumbed out through other perf interfaces.
>>
>> We've used various internal hacks over the years to keep them happy. This is 
>> an
>> attempt to use a somewhat standard mechanism.
>>
>> It would also be helpful for those of us working on the perf hardware 
>> backends,
>> to be able to verify that we're programming things correctly, without 
>> resorting
>> to debug printks etc.
>>
>> Basically we want to sample regs at the time of the perf interrupt, so we
>> though PERF_SAMPLE_REGS_INTR made senes :)
>>
>> But if you think this is the wrong mechanism within perf, then please let us
>> know.
>>
>> I know perf's mission is to abstract as much of the arcane hardware details
>> into a generic interface and make PMUs actually useful for normal folks, and 
>> we
>> are committed to that, but it would also be useful to be able to get the raw
>> values for a different type of user.
>>
>> Maddy's patch only exports PMC1-6 and MMCR0/1. I think we also need to export
>> some others, in particular MMCRA has a lot of stuff in it, half of which is 
>> not
>> even architected. So that would have to be exported as "POWER8_MMCRA". And 
>> then
>> there's the SIAR/SDAR/SIER which contain a bunch of info on sampled
>> instructions that is not currently plumbed out.
> OK, no objections then. But this is useful information and should be
> included in the patch set.
>

Sure. Will add the information in the next version.

Maddy


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 0/3]perf/core: extend perf_reg and perf_sample_regs_intr

[Michael Ellerman]

On Fri, 2015-11-06 at 10:24 +0100, Peter Zijlstra wrote:
> On Fri, Nov 06, 2015 at 12:57:17PM +0530, Madhavan Srinivasan wrote:
> > On Thursday 05 November 2015 06:37 PM, Peter Zijlstra wrote:
> > > On Thu, Nov 05, 2015 at 02:16:15AM +0530, Madhavan Srinivasan wrote:
> > > > Second patch updates struct arch_misc_reg for arch/powerpc with pmu 
> > > > registers
> > > > and adds offsetof macro for the same. It extends perf_reg_value()
> > > > to use reg idx to decide on struct to return value from.
> > > Why; what's in those regs?
> > 
> > Was out and did not have access to mail, so missed to respond in time.
> > 
> > In current implementation of patch 2, have added 
> > few pmu control/status and counter registers,
> > which give additional information about the PMU context
> > for the sample.
> 
> Yes, I saw that, you still haven't answered the question though. What is
> in those regs? Why is exposing that information like this the best
> option.

It's a perrenial request from our hardware PMU folks to be able to see the raw
values of the PMU registers.

I think partly it's so that they can verify that perf is doing what they want,
and some of it is that they're interested in some of the more obscure info that
isn't plumbed out through other perf interfaces.

We've used various internal hacks over the years to keep them happy. This is an
attempt to use a somewhat standard mechanism.

It would also be helpful for those of us working on the perf hardware backends,
to be able to verify that we're programming things correctly, without resorting
to debug printks etc.

Basically we want to sample regs at the time of the perf interrupt, so we
though PERF_SAMPLE_REGS_INTR made senes :)

But if you think this is the wrong mechanism within perf, then please let us
know.

I know perf's mission is to abstract as much of the arcane hardware details
into a generic interface and make PMUs actually useful for normal folks, and we
are committed to that, but it would also be useful to be able to get the raw
values for a different type of user.

Maddy's patch only exports PMC1-6 and MMCR0/1. I think we also need to export
some others, in particular MMCRA has a lot of stuff in it, half of which is not
even architected. So that would have to be exported as "POWER8_MMCRA". And then
there's the SIAR/SDAR/SIER which contain a bunch of info on sampled
instructions that is not currently plumbed out.

cheers

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 0/3]perf/core: extend perf_reg and perf_sample_regs_intr

[Peter Zijlstra]

On Fri, Nov 06, 2015 at 09:04:00PM +1100, Michael Ellerman wrote:
> It's a perrenial request from our hardware PMU folks to be able to see the raw
> values of the PMU registers.
> 
> I think partly it's so that they can verify that perf is doing what they want,
> and some of it is that they're interested in some of the more obscure info 
> that
> isn't plumbed out through other perf interfaces.
> 
> We've used various internal hacks over the years to keep them happy. This is 
> an
> attempt to use a somewhat standard mechanism.
> 
> It would also be helpful for those of us working on the perf hardware 
> backends,
> to be able to verify that we're programming things correctly, without 
> resorting
> to debug printks etc.
> 
> Basically we want to sample regs at the time of the perf interrupt, so we
> though PERF_SAMPLE_REGS_INTR made senes :)
> 
> But if you think this is the wrong mechanism within perf, then please let us
> know.
> 
> I know perf's mission is to abstract as much of the arcane hardware details
> into a generic interface and make PMUs actually useful for normal folks, and 
> we
> are committed to that, but it would also be useful to be able to get the raw
> values for a different type of user.
> 
> Maddy's patch only exports PMC1-6 and MMCR0/1. I think we also need to export
> some others, in particular MMCRA has a lot of stuff in it, half of which is 
> not
> even architected. So that would have to be exported as "POWER8_MMCRA". And 
> then
> there's the SIAR/SDAR/SIER which contain a bunch of info on sampled
> instructions that is not currently plumbed out.

OK, no objections then. But this is useful information and should be
included in the patch set.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 0/3]perf/core: extend perf_reg and perf_sample_regs_intr

[Michael Ellerman]

On Fri, 2015-11-06 at 13:17 +0530, Madhavan Srinivasan wrote:
> On Friday 06 November 2015 08:28 AM, Sukadev Bhattiprolu wrote:
> > Peter Zijlstra [pet...@infradead.org] wrote:
> > > On Thu, Nov 05, 2015 at 02:16:15AM +0530, Madhavan Srinivasan wrote:
> > > > Second patch updates struct arch_misc_reg for arch/powerpc with pmu 
> > > > registers
> > > > and adds offsetof macro for the same. It extends perf_reg_value()
> > > > to use reg idx to decide on struct to return value from.
> > > 
> > > Why; what's in those regs?
> > 
> > Those are PMU control registers/counters (in Patch 2) that are of
> > interest only in the context of a PMU interrupt and not relevant
> > to ptrace itself.
> 
> Yes. Thats right.

> > Could we add those registers to 'struct pt_regs' anyway?
> 
> I would prefer not to. Since as you mentioned, these are
> not relevant to ptrace. Currently patch 2, adds only few
> pmu registers, but would like to include more.

You can't just add them to pt_regs, it's part of the userspace ABI.

We could define a kernel internal version of pt_regs, but I don't think we want
to for this.

If we did that would bloat pt_regs for all users in the kernel, when we really
only want these regs for perf.

cheers

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 0/3]perf/core: extend perf_reg and perf_sample_regs_intr

[Peter Zijlstra]

On Fri, Nov 06, 2015 at 12:57:17PM +0530, Madhavan Srinivasan wrote:
> 
> 
> On Thursday 05 November 2015 06:37 PM, Peter Zijlstra wrote:
> > On Thu, Nov 05, 2015 at 02:16:15AM +0530, Madhavan Srinivasan wrote:
> >> Second patch updates struct arch_misc_reg for arch/powerpc with pmu 
> >> registers
> >> and adds offsetof macro for the same. It extends perf_reg_value()
> >> to use reg idx to decide on struct to return value from.
> > Why; what's in those regs?
> 
> Was out and did not have access to mail, so missed to respond in time.
> 
> In current implementation of patch 2, have added 
> few pmu control/status and counter registers,
> which give additional information about the PMU context
> for the sample.

Yes, I saw that, you still haven't answered the question though. What is
in those regs? Why is exposing that information like this the best
option.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 0/3]perf/core: extend perf_reg and perf_sample_regs_intr

[Madhavan Srinivasan]

On Friday 06 November 2015 08:28 AM, Sukadev Bhattiprolu wrote:
> Peter Zijlstra [pet...@infradead.org] wrote:
> | On Thu, Nov 05, 2015 at 02:16:15AM +0530, Madhavan Srinivasan wrote:
> | > Second patch updates struct arch_misc_reg for arch/powerpc with pmu 
> registers
> | > and adds offsetof macro for the same. It extends perf_reg_value()
> | > to use reg idx to decide on struct to return value from.
> | 
> | Why; what's in those regs?
>
> Those are PMU control registers/counters (in Patch 2) that are of
> interest only in the context of a PMU interrupt and not relevant
> to ptrace itself.

Yes. Thats right.

> Could we add those registers to 'struct pt_regs' anyway?

I would prefer not to. Since as you mentioned, these are
not relevant to ptrace. Currently patch 2, adds only few
pmu registers, but would like to include more.
 
> We do have 'struct perf_regs' but that seems to be arch nuetral.
> If architectures could override that, maybe we could add these
> new registers there without touching 'struct pt_regs'.

Exactly, idea here is to capture more data using perf_sample_reg_intr
without extending pt_regs structure.

Maddy

> Even so, lot of perf code depends on 'struct pt_regs'.
>
> Sukadev

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 0/3]perf/core: extend perf_reg and perf_sample_regs_intr

[Madhavan Srinivasan]

On Thursday 05 November 2015 08:12 PM, Stephane Eranian wrote:
> Hi,
>
> On Wed, Nov 4, 2015 at 9:46 PM, Madhavan Srinivasan
>  wrote:
>> This patchset extend the perf sample regs infrastructure
>> to include architecture specific regs. Current perf_sample_regs_intr
>> exports only registers in the pt_regs to perf.data using
>> PERF_SAMPLE_REGS_INTR sample type. But sometimes we end up looking
>> for or prefer raw register values at the interrupt during debug.
>>
> I don't quite understand this explanation here.
> What do you mean by raw register values?
> The content of pt_regs is also raw register values at interrupt.

Was out and did not have access to mail, so missed to respond in time.

Yes. that is right. My bad. Did not effectively communicate
what I intended. Intend here is to capture more data related to
pmu context for the sample.

And in case of arch/powerpc, only a subset of pmu regs are
in the pt_regs structure. By adding these  additional pmu registers
(which are not part of pt_regs and i dont intend to overload
pt_regs struct with these regs, since it is not relevant to ptrace),
more interesting data about the PMU and its context is captured
for the sample.

> The API does not say that the content of perf_sample_regs_intr can ONLY
> contain names of registers coming from pt_regs. The meaning of each bit
> is arch specific and you are free to map to whatever is relevant for your 
> arch.
> All the API says is that the values captured in the sampling buffer for these
> registers are taken at PMU interrupt.
Yes thats right. But what I propose here to include an
arch specific struct in the perf_regs, so that more register values
can be fetched as part of perf_sample_regs_intr without
extending pt_regs.

Maddy

>> This patchset extends the perf_regs to include arch specific struct,
>> and makes perf_sample_regs_intr in kernel/event/core.c as __weak__
>> function. This way, an arch specific implementation of
>> perf_sample_regs_intr() can update the arch specific data to
>> the perf_regs.
>>
>> First patch defines a new structure arch_misc_reg and updates the same
>> in the struct perf_regs. Patch also modifies the perf_reg_value()
>> and perf_output_sample_regs() to take perf_regs parameter instead of pt_regs.
>>
>> Second patch updates struct arch_misc_reg for arch/powerpc with pmu registers
>> and adds offsetof macro for the same. It extends perf_reg_value()
>> to use reg idx to decide on struct to return value from.
>>
>> Third patch adds arch specific perf_sample_regs_intr() in arch/powerpc
>> to hook up the arch_misc_regs to perf_regs.
>>
>> This patchset depends on the recent posting by Anju T in
>> linuxppc-...@lists.ozlabs.org to enable PERF_SAMPLE_REGS_INTR
>> support in arch/powerpc.
>>
>> https://patchwork.ozlabs.org/patch/539242/
>> https://patchwork.ozlabs.org/patch/539243/
>> https://patchwork.ozlabs.org/patch/539244/
>>
>> Would appreciate comments and feedback.
>>
>> Signed-off-by: Madhavan Srinivasan 
>> Cc: Thomas Gleixner 
>> Cc: Ingo Molnar 
>> Cc: Peter Zijlstra 
>> Cc: Jiri Olsa 
>> Cc: Arnaldo Carvalho de Melo 
>> Cc: Stephane Eranian 
>> Cc: Russell King 
>> Cc: Catalin Marinas 
>> Cc: Will Deacon 
>> Cc: Benjamin Herrenschmidt 
>> Cc: Michael Ellerman 
>> Cc: Sukadev Bhattiprolu 
>>
>> Madhavan Srinivasan (3):
>>   perf/core: extend perf_regs to include arch specific regs
>>   perf/powerpc: update macros and add regs to arch_misc_reg struct
>>   perf/powerpc: Functions to update arch_misc_regs
>>
>>  arch/arm/include/asm/ptrace.h   |  2 ++
>>  arch/arm/kernel/perf_regs.c |  4 +++-
>>  arch/arm64/include/asm/ptrace.h |  2 ++
>>  arch/arm64/kernel/perf_regs.c   |  4 +++-
>>  arch/powerpc/include/uapi/asm/perf_regs.h   | 10 ++
>>  arch/powerpc/include/uapi/asm/ptrace.h  | 11 +++
>>  arch/powerpc/perf/core-book3s.c | 29 
>> +
>>  arch/powerpc/perf/perf_regs.c   | 28 
>> ++--
>>  arch/x86/include/asm/ptrace.h   |  2 ++
>>  arch/x86/kernel/perf_regs.c |  4 +++-
>>  include/linux/perf_regs.h   |  5 +++--
>>  kernel/events/core.c|  8 
>>  tools/perf/arch/powerpc/include/perf_regs.h | 16 
>>  13 files changed, 114 insertions(+), 11 deletions(-)
>>
>> --
>> 1.9.1
>>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 0/3]perf/core: extend perf_reg and perf_sample_regs_intr

[Madhavan Srinivasan]

On Thursday 05 November 2015 06:37 PM, Peter Zijlstra wrote:
> On Thu, Nov 05, 2015 at 02:16:15AM +0530, Madhavan Srinivasan wrote:
>> Second patch updates struct arch_misc_reg for arch/powerpc with pmu registers
>> and adds offsetof macro for the same. It extends perf_reg_value()
>> to use reg idx to decide on struct to return value from.
> Why; what's in those regs?

Was out and did not have access to mail, so missed to respond in time.

In current implementation of patch 2, have added 
few pmu control/status and counter registers,
which give additional information about the PMU context
for the sample.

These pmu registers are not relevant for ptrace and did not
want to overload pt_regs struct.

Adding these arch specific regs in perf_regs will break the "arch
neutral" part, and
other arch can also use this new struct in perf_regs to add more data
using perf_sample_regs_intr without extending the pt_regs.

Maddy


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 0/3]perf/core: extend perf_reg and perf_sample_regs_intr

[Sukadev Bhattiprolu]

Peter Zijlstra [pet...@infradead.org] wrote:
| On Thu, Nov 05, 2015 at 02:16:15AM +0530, Madhavan Srinivasan wrote:
| > Second patch updates struct arch_misc_reg for arch/powerpc with pmu 
registers
| > and adds offsetof macro for the same. It extends perf_reg_value()
| > to use reg idx to decide on struct to return value from.
| 
| Why; what's in those regs?

Those are PMU control registers/counters (in Patch 2) that are of
interest only in the context of a PMU interrupt and not relevant
to ptrace itself.

Could we add those registers to 'struct pt_regs' anyway?

We do have 'struct perf_regs' but that seems to be arch nuetral.
If architectures could override that, maybe we could add these
new registers there without touching 'struct pt_regs'.

Even so, lot of perf code depends on 'struct pt_regs'.

Sukadev

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 0/3]perf/core: extend perf_reg and perf_sample_regs_intr

[Stephane Eranian]

Hi,

On Wed, Nov 4, 2015 at 9:46 PM, Madhavan Srinivasan
 wrote:
>
> This patchset extend the perf sample regs infrastructure
> to include architecture specific regs. Current perf_sample_regs_intr
> exports only registers in the pt_regs to perf.data using
> PERF_SAMPLE_REGS_INTR sample type. But sometimes we end up looking
> for or prefer raw register values at the interrupt during debug.
>
I don't quite understand this explanation here.
What do you mean by raw register values?
The content of pt_regs is also raw register values at interrupt.

The API does not say that the content of perf_sample_regs_intr can ONLY
contain names of registers coming from pt_regs. The meaning of each bit
is arch specific and you are free to map to whatever is relevant for your arch.
All the API says is that the values captured in the sampling buffer for these
registers are taken at PMU interrupt.

>
> This patchset extends the perf_regs to include arch specific struct,
> and makes perf_sample_regs_intr in kernel/event/core.c as __weak__
> function. This way, an arch specific implementation of
> perf_sample_regs_intr() can update the arch specific data to
> the perf_regs.
>
> First patch defines a new structure arch_misc_reg and updates the same
> in the struct perf_regs. Patch also modifies the perf_reg_value()
> and perf_output_sample_regs() to take perf_regs parameter instead of pt_regs.
>
> Second patch updates struct arch_misc_reg for arch/powerpc with pmu registers
> and adds offsetof macro for the same. It extends perf_reg_value()
> to use reg idx to decide on struct to return value from.
>
> Third patch adds arch specific perf_sample_regs_intr() in arch/powerpc
> to hook up the arch_misc_regs to perf_regs.
>
> This patchset depends on the recent posting by Anju T in
> linuxppc-...@lists.ozlabs.org to enable PERF_SAMPLE_REGS_INTR
> support in arch/powerpc.
>
> https://patchwork.ozlabs.org/patch/539242/
> https://patchwork.ozlabs.org/patch/539243/
> https://patchwork.ozlabs.org/patch/539244/
>
> Would appreciate comments and feedback.
>
> Signed-off-by: Madhavan Srinivasan 
> Cc: Thomas Gleixner 
> Cc: Ingo Molnar 
> Cc: Peter Zijlstra 
> Cc: Jiri Olsa 
> Cc: Arnaldo Carvalho de Melo 
> Cc: Stephane Eranian 
> Cc: Russell King 
> Cc: Catalin Marinas 
> Cc: Will Deacon 
> Cc: Benjamin Herrenschmidt 
> Cc: Michael Ellerman 
> Cc: Sukadev Bhattiprolu 
>
> Madhavan Srinivasan (3):
>   perf/core: extend perf_regs to include arch specific regs
>   perf/powerpc: update macros and add regs to arch_misc_reg struct
>   perf/powerpc: Functions to update arch_misc_regs
>
>  arch/arm/include/asm/ptrace.h   |  2 ++
>  arch/arm/kernel/perf_regs.c |  4 +++-
>  arch/arm64/include/asm/ptrace.h |  2 ++
>  arch/arm64/kernel/perf_regs.c   |  4 +++-
>  arch/powerpc/include/uapi/asm/perf_regs.h   | 10 ++
>  arch/powerpc/include/uapi/asm/ptrace.h  | 11 +++
>  arch/powerpc/perf/core-book3s.c | 29 
> +
>  arch/powerpc/perf/perf_regs.c   | 28 ++--
>  arch/x86/include/asm/ptrace.h   |  2 ++
>  arch/x86/kernel/perf_regs.c |  4 +++-
>  include/linux/perf_regs.h   |  5 +++--
>  kernel/events/core.c|  8 
>  tools/perf/arch/powerpc/include/perf_regs.h | 16 
>  13 files changed, 114 insertions(+), 11 deletions(-)
>
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 0/3]perf/core: extend perf_reg and perf_sample_regs_intr

[Peter Zijlstra]

On Thu, Nov 05, 2015 at 02:16:15AM +0530, Madhavan Srinivasan wrote:
> Second patch updates struct arch_misc_reg for arch/powerpc with pmu registers
> and adds offsetof macro for the same. It extends perf_reg_value()
> to use reg idx to decide on struct to return value from.

Why; what's in those regs?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 0/3]perf/core: extend perf_reg and perf_sample_regs_intr

[Peter Zijlstra]

On Thu, Nov 05, 2015 at 02:16:15AM +0530, Madhavan Srinivasan wrote:
> Second patch updates struct arch_misc_reg for arch/powerpc with pmu registers
> and adds offsetof macro for the same. It extends perf_reg_value()
> to use reg idx to decide on struct to return value from.

Why; what's in those regs?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 0/3]perf/core: extend perf_reg and perf_sample_regs_intr

[Sukadev Bhattiprolu]

Peter Zijlstra [pet...@infradead.org] wrote:
| On Thu, Nov 05, 2015 at 02:16:15AM +0530, Madhavan Srinivasan wrote:
| > Second patch updates struct arch_misc_reg for arch/powerpc with pmu 
registers
| > and adds offsetof macro for the same. It extends perf_reg_value()
| > to use reg idx to decide on struct to return value from.
| 
| Why; what's in those regs?

Those are PMU control registers/counters (in Patch 2) that are of
interest only in the context of a PMU interrupt and not relevant
to ptrace itself.

Could we add those registers to 'struct pt_regs' anyway?

We do have 'struct perf_regs' but that seems to be arch nuetral.
If architectures could override that, maybe we could add these
new registers there without touching 'struct pt_regs'.

Even so, lot of perf code depends on 'struct pt_regs'.

Sukadev

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 0/3]perf/core: extend perf_reg and perf_sample_regs_intr

[Madhavan Srinivasan]

On Thursday 05 November 2015 08:12 PM, Stephane Eranian wrote:
> Hi,
>
> On Wed, Nov 4, 2015 at 9:46 PM, Madhavan Srinivasan
>  wrote:
>> This patchset extend the perf sample regs infrastructure
>> to include architecture specific regs. Current perf_sample_regs_intr
>> exports only registers in the pt_regs to perf.data using
>> PERF_SAMPLE_REGS_INTR sample type. But sometimes we end up looking
>> for or prefer raw register values at the interrupt during debug.
>>
> I don't quite understand this explanation here.
> What do you mean by raw register values?
> The content of pt_regs is also raw register values at interrupt.

Was out and did not have access to mail, so missed to respond in time.

Yes. that is right. My bad. Did not effectively communicate
what I intended. Intend here is to capture more data related to
pmu context for the sample.

And in case of arch/powerpc, only a subset of pmu regs are
in the pt_regs structure. By adding these  additional pmu registers
(which are not part of pt_regs and i dont intend to overload
pt_regs struct with these regs, since it is not relevant to ptrace),
more interesting data about the PMU and its context is captured
for the sample.

> The API does not say that the content of perf_sample_regs_intr can ONLY
> contain names of registers coming from pt_regs. The meaning of each bit
> is arch specific and you are free to map to whatever is relevant for your 
> arch.
> All the API says is that the values captured in the sampling buffer for these
> registers are taken at PMU interrupt.
Yes thats right. But what I propose here to include an
arch specific struct in the perf_regs, so that more register values
can be fetched as part of perf_sample_regs_intr without
extending pt_regs.

Maddy

>> This patchset extends the perf_regs to include arch specific struct,
>> and makes perf_sample_regs_intr in kernel/event/core.c as __weak__
>> function. This way, an arch specific implementation of
>> perf_sample_regs_intr() can update the arch specific data to
>> the perf_regs.
>>
>> First patch defines a new structure arch_misc_reg and updates the same
>> in the struct perf_regs. Patch also modifies the perf_reg_value()
>> and perf_output_sample_regs() to take perf_regs parameter instead of pt_regs.
>>
>> Second patch updates struct arch_misc_reg for arch/powerpc with pmu registers
>> and adds offsetof macro for the same. It extends perf_reg_value()
>> to use reg idx to decide on struct to return value from.
>>
>> Third patch adds arch specific perf_sample_regs_intr() in arch/powerpc
>> to hook up the arch_misc_regs to perf_regs.
>>
>> This patchset depends on the recent posting by Anju T in
>> linuxppc-...@lists.ozlabs.org to enable PERF_SAMPLE_REGS_INTR
>> support in arch/powerpc.
>>
>> https://patchwork.ozlabs.org/patch/539242/
>> https://patchwork.ozlabs.org/patch/539243/
>> https://patchwork.ozlabs.org/patch/539244/
>>
>> Would appreciate comments and feedback.
>>
>> Signed-off-by: Madhavan Srinivasan 
>> Cc: Thomas Gleixner 
>> Cc: Ingo Molnar 
>> Cc: Peter Zijlstra 
>> Cc: Jiri Olsa 
>> Cc: Arnaldo Carvalho de Melo 
>> Cc: Stephane Eranian 
>> Cc: Russell King 
>> Cc: Catalin Marinas 
>> Cc: Will Deacon 
>> Cc: Benjamin Herrenschmidt 
>> Cc: Michael Ellerman 
>> Cc: Sukadev Bhattiprolu 
>>
>> Madhavan Srinivasan (3):
>>   perf/core: extend perf_regs to include arch specific regs
>>   perf/powerpc: update macros and add regs to arch_misc_reg struct
>>   perf/powerpc: Functions to update arch_misc_regs
>>
>>  arch/arm/include/asm/ptrace.h   |  2 ++
>>  arch/arm/kernel/perf_regs.c |  4 +++-
>>  arch/arm64/include/asm/ptrace.h |  2 ++
>>  arch/arm64/kernel/perf_regs.c   |  4 +++-
>>  arch/powerpc/include/uapi/asm/perf_regs.h   | 10 ++
>>  arch/powerpc/include/uapi/asm/ptrace.h  | 11 +++
>>  arch/powerpc/perf/core-book3s.c | 29 
>> +
>>  arch/powerpc/perf/perf_regs.c   | 28 
>> ++--
>>  arch/x86/include/asm/ptrace.h   |  2 ++
>>  arch/x86/kernel/perf_regs.c |  4 +++-
>>  include/linux/perf_regs.h   |  5 +++--
>>  kernel/events/core.c|  8 
>>  tools/perf/arch/powerpc/include/perf_regs.h | 16 
>>  13 files changed, 114 insertions(+), 11 deletions(-)
>>
>> --
>> 1.9.1
>>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 0/3]perf/core: extend perf_reg and perf_sample_regs_intr

[Madhavan Srinivasan]

On Thursday 05 November 2015 06:37 PM, Peter Zijlstra wrote:
> On Thu, Nov 05, 2015 at 02:16:15AM +0530, Madhavan Srinivasan wrote:
>> Second patch updates struct arch_misc_reg for arch/powerpc with pmu registers
>> and adds offsetof macro for the same. It extends perf_reg_value()
>> to use reg idx to decide on struct to return value from.
> Why; what's in those regs?

Was out and did not have access to mail, so missed to respond in time.

In current implementation of patch 2, have added 
few pmu control/status and counter registers,
which give additional information about the PMU context
for the sample.

These pmu registers are not relevant for ptrace and did not
want to overload pt_regs struct.

Adding these arch specific regs in perf_regs will break the "arch
neutral" part, and
other arch can also use this new struct in perf_regs to add more data
using perf_sample_regs_intr without extending the pt_regs.

Maddy


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 0/3]perf/core: extend perf_reg and perf_sample_regs_intr

[Madhavan Srinivasan]

On Friday 06 November 2015 08:28 AM, Sukadev Bhattiprolu wrote:
> Peter Zijlstra [pet...@infradead.org] wrote:
> | On Thu, Nov 05, 2015 at 02:16:15AM +0530, Madhavan Srinivasan wrote:
> | > Second patch updates struct arch_misc_reg for arch/powerpc with pmu 
> registers
> | > and adds offsetof macro for the same. It extends perf_reg_value()
> | > to use reg idx to decide on struct to return value from.
> | 
> | Why; what's in those regs?
>
> Those are PMU control registers/counters (in Patch 2) that are of
> interest only in the context of a PMU interrupt and not relevant
> to ptrace itself.

Yes. Thats right.

> Could we add those registers to 'struct pt_regs' anyway?

I would prefer not to. Since as you mentioned, these are
not relevant to ptrace. Currently patch 2, adds only few
pmu registers, but would like to include more.
 
> We do have 'struct perf_regs' but that seems to be arch nuetral.
> If architectures could override that, maybe we could add these
> new registers there without touching 'struct pt_regs'.

Exactly, idea here is to capture more data using perf_sample_reg_intr
without extending pt_regs structure.

Maddy

> Even so, lot of perf code depends on 'struct pt_regs'.
>
> Sukadev

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 0/3]perf/core: extend perf_reg and perf_sample_regs_intr

[Stephane Eranian]

Hi,

On Wed, Nov 4, 2015 at 9:46 PM, Madhavan Srinivasan
 wrote:
>
> This patchset extend the perf sample regs infrastructure
> to include architecture specific regs. Current perf_sample_regs_intr
> exports only registers in the pt_regs to perf.data using
> PERF_SAMPLE_REGS_INTR sample type. But sometimes we end up looking
> for or prefer raw register values at the interrupt during debug.
>
I don't quite understand this explanation here.
What do you mean by raw register values?
The content of pt_regs is also raw register values at interrupt.

The API does not say that the content of perf_sample_regs_intr can ONLY
contain names of registers coming from pt_regs. The meaning of each bit
is arch specific and you are free to map to whatever is relevant for your arch.
All the API says is that the values captured in the sampling buffer for these
registers are taken at PMU interrupt.

>
> This patchset extends the perf_regs to include arch specific struct,
> and makes perf_sample_regs_intr in kernel/event/core.c as __weak__
> function. This way, an arch specific implementation of
> perf_sample_regs_intr() can update the arch specific data to
> the perf_regs.
>
> First patch defines a new structure arch_misc_reg and updates the same
> in the struct perf_regs. Patch also modifies the perf_reg_value()
> and perf_output_sample_regs() to take perf_regs parameter instead of pt_regs.
>
> Second patch updates struct arch_misc_reg for arch/powerpc with pmu registers
> and adds offsetof macro for the same. It extends perf_reg_value()
> to use reg idx to decide on struct to return value from.
>
> Third patch adds arch specific perf_sample_regs_intr() in arch/powerpc
> to hook up the arch_misc_regs to perf_regs.
>
> This patchset depends on the recent posting by Anju T in
> linuxppc-...@lists.ozlabs.org to enable PERF_SAMPLE_REGS_INTR
> support in arch/powerpc.
>
> https://patchwork.ozlabs.org/patch/539242/
> https://patchwork.ozlabs.org/patch/539243/
> https://patchwork.ozlabs.org/patch/539244/
>
> Would appreciate comments and feedback.
>
> Signed-off-by: Madhavan Srinivasan 
> Cc: Thomas Gleixner 
> Cc: Ingo Molnar 
> Cc: Peter Zijlstra 
> Cc: Jiri Olsa 
> Cc: Arnaldo Carvalho de Melo 
> Cc: Stephane Eranian 
> Cc: Russell King 
> Cc: Catalin Marinas 
> Cc: Will Deacon 
> Cc: Benjamin Herrenschmidt 
> Cc: Michael Ellerman 
> Cc: Sukadev Bhattiprolu 
>
> Madhavan Srinivasan (3):
>   perf/core: extend perf_regs to include arch specific regs
>   perf/powerpc: update macros and add regs to arch_misc_reg struct
>   perf/powerpc: Functions to update arch_misc_regs
>
>  arch/arm/include/asm/ptrace.h   |  2 ++
>  arch/arm/kernel/perf_regs.c |  4 +++-
>  arch/arm64/include/asm/ptrace.h |  2 ++
>  arch/arm64/kernel/perf_regs.c   |  4 +++-
>  arch/powerpc/include/uapi/asm/perf_regs.h   | 10 ++
>  arch/powerpc/include/uapi/asm/ptrace.h  | 11 +++
>  arch/powerpc/perf/core-book3s.c | 29 
> +
>  arch/powerpc/perf/perf_regs.c   | 28 ++--
>  arch/x86/include/asm/ptrace.h   |  2 ++
>  arch/x86/kernel/perf_regs.c |  4 +++-
>  include/linux/perf_regs.h   |  5 +++--
>  kernel/events/core.c|  8 
>  tools/perf/arch/powerpc/include/perf_regs.h | 16 
>  13 files changed, 114 insertions(+), 11 deletions(-)
>
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/