Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1256863 > unrolled thread

Re: [PATCH] arm: perf: Add event descriptions

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] arm: perf: Add event descriptions Christopher Covington <cov@codeaurora.org> - 2015-10-27 16:50 +0100
    Re: [PATCH] arm: perf: Add event descriptions Mark Rutland <mark.rutland@arm.com> - 2015-10-27 17:10 +0100
      Re: [PATCH] arm: perf: Add event descriptions Christopher Covington <cov@codeaurora.org> - 2015-10-28 15:20 +0100
        Re: [PATCH] arm: perf: Add event descriptions Mark Rutland <mark.rutland@arm.com> - 2015-10-28 15:30 +0100

#1256863 — Re: [PATCH] arm: perf: Add event descriptions

On 10/07/2015 07:20 AM, Will Deacon wrote:
> Hi again, Drew,
> 
> On Thu, Sep 24, 2015 at 06:52:57PM +0100, Will Deacon wrote:
>> On Mon, Aug 17, 2015 at 10:40:36PM +0100, Drew Richardson wrote:
>>> So my suggestion to solve the problem is that the kernel can have the
>>> list of events as proposed in the patch.
>>
>> Sorry, but I just don't buy this argument. Your problem is that the user
>> needs to be running an up-to-date perf tool, but with your proposed
>> solution, you're asking them to update the *kernel* instead, which is
>> (unfortunately) one of the hardest pieces of software to upgrade on a
>> typical ARM platform.
> 
> I've spent some time thinking about this and, actually, it makes sense
> to do this for the architected events. These event numbers are guaranteed
> to be portable between CPUs, so if we expose those through sysfs then
> we don't have this dependency on updating the kernel for newer cores
> (well, once the initial period without your patch has expired). It's the
> noon-portable, micro-architectural events that I object to.
> 
> So how about you roll a new version of this patch just exposing the
> architected events and making use of the macros in perf_event.h to make
> it a bit tidier (PMU_EVENT_ATTR, PMU_EVENT_ATTR_STRING etc)?
> 
> Be aware that there's a fair amount of arm64 perf patches queue for 4.4,
> since we're moving over to the code in drivers/perf/. Hopefully these
> will appear on the arm64 for-next/core branch shortly.

Have you considered using OF/ACPI to describe this aspect of the hardware?

Thanks,
Christopher Covington

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1256887

On Tue, Oct 27, 2015 at 11:46:12AM -0400, Christopher Covington wrote:
> On 10/07/2015 07:20 AM, Will Deacon wrote:
> > Hi again, Drew,
> > 
> > On Thu, Sep 24, 2015 at 06:52:57PM +0100, Will Deacon wrote:
> >> On Mon, Aug 17, 2015 at 10:40:36PM +0100, Drew Richardson wrote:
> >>> So my suggestion to solve the problem is that the kernel can have the
> >>> list of events as proposed in the patch.
> >>
> >> Sorry, but I just don't buy this argument. Your problem is that the user
> >> needs to be running an up-to-date perf tool, but with your proposed
> >> solution, you're asking them to update the *kernel* instead, which is
> >> (unfortunately) one of the hardest pieces of software to upgrade on a
> >> typical ARM platform.
> > 
> > I've spent some time thinking about this and, actually, it makes sense
> > to do this for the architected events. These event numbers are guaranteed
> > to be portable between CPUs, so if we expose those through sysfs then
> > we don't have this dependency on updating the kernel for newer cores
> > (well, once the initial period without your patch has expired). It's the
> > noon-portable, micro-architectural events that I object to.
> > 
> > So how about you roll a new version of this patch just exposing the
> > architected events and making use of the macros in perf_event.h to make
> > it a bit tidier (PMU_EVENT_ATTR, PMU_EVENT_ATTR_STRING etc)?
> > 
> > Be aware that there's a fair amount of arm64 perf patches queue for 4.4,
> > since we're moving over to the code in drivers/perf/. Hopefully these
> > will appear on the arm64 for-next/core branch shortly.
> 
> Have you considered using OF/ACPI to describe this aspect of the hardware?

FW-provided data structures are going to be harder to upgrade than the
kernel, so the same argument applies as with placing this data in the
kernel (if anything, more strongly).

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

[toc] | [prev] | [next] | [standalone]

#1258140

On 10/27/2015 12:04 PM, Mark Rutland wrote:
> On Tue, Oct 27, 2015 at 11:46:12AM -0400, Christopher Covington wrote:
>> On 10/07/2015 07:20 AM, Will Deacon wrote:
>>> Hi again, Drew,
>>>
>>> On Thu, Sep 24, 2015 at 06:52:57PM +0100, Will Deacon wrote:
>>>> On Mon, Aug 17, 2015 at 10:40:36PM +0100, Drew Richardson wrote:
>>>>> So my suggestion to solve the problem is that the kernel can have the
>>>>> list of events as proposed in the patch.
>>>>
>>>> Sorry, but I just don't buy this argument. Your problem is that the user
>>>> needs to be running an up-to-date perf tool, but with your proposed
>>>> solution, you're asking them to update the *kernel* instead, which is
>>>> (unfortunately) one of the hardest pieces of software to upgrade on a
>>>> typical ARM platform.
>>>
>>> I've spent some time thinking about this and, actually, it makes sense
>>> to do this for the architected events. These event numbers are guaranteed
>>> to be portable between CPUs, so if we expose those through sysfs then
>>> we don't have this dependency on updating the kernel for newer cores
>>> (well, once the initial period without your patch has expired). It's the
>>> noon-portable, micro-architectural events that I object to.
>>>
>>> So how about you roll a new version of this patch just exposing the
>>> architected events and making use of the macros in perf_event.h to make
>>> it a bit tidier (PMU_EVENT_ATTR, PMU_EVENT_ATTR_STRING etc)?
>>>
>>> Be aware that there's a fair amount of arm64 perf patches queue for 4.4,
>>> since we're moving over to the code in drivers/perf/. Hopefully these
>>> will appear on the arm64 for-next/core branch shortly.
>>
>> Have you considered using OF/ACPI to describe this aspect of the hardware?
> 
> FW-provided data structures are going to be harder to upgrade than the
> kernel, so the same argument applies as with placing this data in the
> kernel (if anything, more strongly).

A convenient place for workarounds is great, when necessary, but I don't see
why Plan A for hardware description should be anything other than standardized
hardware description mechanisms.

Why are you eager to inflate the expectations of firmware when it comes to
power state coordination but reluctant to rely on firmware for describing
performance monitor events?

Christopher Covington

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1258161

On Wed, Oct 28, 2015 at 10:14:24AM -0400, Christopher Covington wrote:
> On 10/27/2015 12:04 PM, Mark Rutland wrote:
> > On Tue, Oct 27, 2015 at 11:46:12AM -0400, Christopher Covington wrote:
> >> On 10/07/2015 07:20 AM, Will Deacon wrote:
> >>> Hi again, Drew,
> >>>
> >>> On Thu, Sep 24, 2015 at 06:52:57PM +0100, Will Deacon wrote:
> >>>> On Mon, Aug 17, 2015 at 10:40:36PM +0100, Drew Richardson wrote:
> >>>>> So my suggestion to solve the problem is that the kernel can have the
> >>>>> list of events as proposed in the patch.
> >>>>
> >>>> Sorry, but I just don't buy this argument. Your problem is that the user
> >>>> needs to be running an up-to-date perf tool, but with your proposed
> >>>> solution, you're asking them to update the *kernel* instead, which is
> >>>> (unfortunately) one of the hardest pieces of software to upgrade on a
> >>>> typical ARM platform.
> >>>
> >>> I've spent some time thinking about this and, actually, it makes sense
> >>> to do this for the architected events. These event numbers are guaranteed
> >>> to be portable between CPUs, so if we expose those through sysfs then
> >>> we don't have this dependency on updating the kernel for newer cores
> >>> (well, once the initial period without your patch has expired). It's the
> >>> noon-portable, micro-architectural events that I object to.
> >>>
> >>> So how about you roll a new version of this patch just exposing the
> >>> architected events and making use of the macros in perf_event.h to make
> >>> it a bit tidier (PMU_EVENT_ATTR, PMU_EVENT_ATTR_STRING etc)?
> >>>
> >>> Be aware that there's a fair amount of arm64 perf patches queue for 4.4,
> >>> since we're moving over to the code in drivers/perf/. Hopefully these
> >>> will appear on the arm64 for-next/core branch shortly.
> >>
> >> Have you considered using OF/ACPI to describe this aspect of the hardware?
> > 
> > FW-provided data structures are going to be harder to upgrade than the
> > kernel, so the same argument applies as with placing this data in the
> > kernel (if anything, more strongly).
> 
> A convenient place for workarounds is great, when necessary, but I don't see
> why Plan A for hardware description should be anything other than standardized
> hardware description mechanisms.
> 
> Why are you eager to inflate the expectations of firmware when it comes to
> power state coordination but reluctant to rely on firmware for describing
> performance monitor events?

Firmware has the responsibility to describe the integration details of
the PMU (the interrupt routing), because that varies between platforms.
The set of supported events does not, for a given PMU (e.g. the events
supported by a Cortex-A57 are the same regardless of whether it's
integrated an ARM Juno or an AMD Seattle), and are effectively part of
the programming model of the device.

Power state coordination is very much platform specific; and is not
comparable.

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web