Re: [PATCH 20/41] perf tools: Let a user specify a PMU event without any config terms
On Tue, Sep 02, 2014 at 08:39:56AM +0300, Adrian Hunter wrote: SNIP > >>> -e intel_pt/tsc=1,noretcomp=0/ > >>> > >>> I guess I wanted to hear more elaboration why is this better > >>> than the current way we have by defining an alias, like: > >>> > >>> krava alias: "tsc=1,noretcomp=0" > >>> > >>> -e intel_pt/krava/ > >>> > >>> which gives the same result > >> > >> The default value must be provided by perf tools not the kernel e.g. > >> an older version of perf tools will not be aware of new hardware > >> features that the kernel may know about. If the kernel enables > >> new features by default then the tool may fail. Thus the default > >> value has to be under the control of the tools not the kernel, so > >> a sysfs alias will not work. > >> > > > > I dont follow, could u provide some example? > > Imagine that the 'tsc' term did not exist. Intel PT trace data > would not contain TSC packets, and the decoder would not know how to > decode them. Then imagine that a new version of the hardware adds > 'tsc'. It is such a useful feature that we want it by default, but > older versions of the tools don't know how to decode it, so the > kernel cannot turn it on by default. > > > > > why the tool needs to understand.. it will just take the alias > > and apply/use it? The alias follows the format logic, which tells > > how to apply values on perf_event_attr.. and the kernel knows best > > what's supported in its version.. > > It is similar to why the kernel does not select mmap2 by default. The > kernel doesn't know whether the tool supports it. > ook, could you please add some kind of this explanation to the changelog? thanks, jirka -- 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: [PATCH 20/41] perf tools: Let a user specify a PMU event without any config terms
On Tue, Sep 02, 2014 at 08:39:56AM +0300, Adrian Hunter wrote: SNIP -e intel_pt/tsc=1,noretcomp=0/ I guess I wanted to hear more elaboration why is this better than the current way we have by defining an alias, like: krava alias: tsc=1,noretcomp=0 -e intel_pt/krava/ which gives the same result The default value must be provided by perf tools not the kernel e.g. an older version of perf tools will not be aware of new hardware features that the kernel may know about. If the kernel enables new features by default then the tool may fail. Thus the default value has to be under the control of the tools not the kernel, so a sysfs alias will not work. I dont follow, could u provide some example? Imagine that the 'tsc' term did not exist. Intel PT trace data would not contain TSC packets, and the decoder would not know how to decode them. Then imagine that a new version of the hardware adds 'tsc'. It is such a useful feature that we want it by default, but older versions of the tools don't know how to decode it, so the kernel cannot turn it on by default. why the tool needs to understand.. it will just take the alias and apply/use it? The alias follows the format logic, which tells how to apply values on perf_event_attr.. and the kernel knows best what's supported in its version.. It is similar to why the kernel does not select mmap2 by default. The kernel doesn't know whether the tool supports it. ook, could you please add some kind of this explanation to the changelog? thanks, jirka -- 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: [PATCH 20/41] perf tools: Let a user specify a PMU event without any config terms
On 09/01/2014 10:11 PM, Jiri Olsa wrote: > On Mon, Sep 01, 2014 at 09:27:17AM +0300, Adrian Hunter wrote: >> On 08/30/2014 11:53 AM, Jiri Olsa wrote: >>> On Fri, Aug 29, 2014 at 09:48:51PM +0300, Adrian Hunter wrote: On 16/07/2014 9:22 p.m., Jiri Olsa wrote: > On Wed, Jul 16, 2014 at 06:04:44PM +0300, Adrian Hunter wrote: >> On 16/07/2014 5:25 p.m., Jiri Olsa wrote: >>> On Mon, Jul 14, 2014 at 01:02:44PM +0300, Adrian Hunter wrote: This enables a PMU event to be specified in the form: pmu// which is effectively the same as: pmu/config=0/ This patch is a precursor to defining default config for a PMU. >>> >>> I understand the need for default config, but could you please elaborate >>> why do we want to parse 'pmu//' as an event string string? >> >> Currently the parser requires the slashes to identify a PMU event >> as opposed to a hardware or other kind of event. > > right, so why do we want to parse 'pmu//' as an event string? ;-) I am not sure what you mean. Here I am using 'pmu' as a placeholder for a real PMU name. So actual event strings are 'intel_bts//' or 'intel_pt//' or 'intel_pt/tsc=0,noretcomp=1/' >>> >>> so the consequence of default arguments is that you can >>> specify event just by the pmu name, like: >>> -e intel_pt// >>> >>> which means (with default attributes): >>> -e intel_pt/tsc=1,noretcomp=0/ >>> >>> I guess I wanted to hear more elaboration why is this better >>> than the current way we have by defining an alias, like: >>> >>> krava alias: "tsc=1,noretcomp=0" >>> >>> -e intel_pt/krava/ >>> >>> which gives the same result >> >> The default value must be provided by perf tools not the kernel e.g. >> an older version of perf tools will not be aware of new hardware >> features that the kernel may know about. If the kernel enables >> new features by default then the tool may fail. Thus the default >> value has to be under the control of the tools not the kernel, so >> a sysfs alias will not work. >> > > I dont follow, could u provide some example? Imagine that the 'tsc' term did not exist. Intel PT trace data would not contain TSC packets, and the decoder would not know how to decode them. Then imagine that a new version of the hardware adds 'tsc'. It is such a useful feature that we want it by default, but older versions of the tools don't know how to decode it, so the kernel cannot turn it on by default. > > why the tool needs to understand.. it will just take the alias > and apply/use it? The alias follows the format logic, which tells > how to apply values on perf_event_attr.. and the kernel knows best > what's supported in its version.. It is similar to why the kernel does not select mmap2 by default. The kernel doesn't know whether the tool supports it. -- 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: [PATCH 20/41] perf tools: Let a user specify a PMU event without any config terms
On Mon, Sep 01, 2014 at 12:51:42PM -0300, Arnaldo Carvalho de Melo wrote: SNIP > > krava alias: "tsc=1,noretcomp=0" > > > -e intel_pt/krava/ > > > which gives the same result > > So you propose that we start maintaining some table of aliases that > would be installed by default, etc? "krava" would not be a good name, I > think (:-)), so in this case we would have something like: > > defaults_intel_pt: "tsc=1,noretcomp=0" > > -e intel_pt/defaults_intel_pt/ > > Which of course gets redundant/long, so, using what Adrian suggests, we > would instead not pass anything between the slashes, and that would mean > "default_" concatenated with the name of the PMU used, so it would > become: > > -e intel_pt// > > that would be equivalent to: > > -e intel_pt/defaults_intel_pt/ > > and also to: > > -e intel_pt/tsc=1,noretcomp=0/ > > ? > > I have not looked at the implementation, this is all just from the > information I skimmed in this thread. well I meant that we already have following directory: /sys/devices/cpu/events for aliases.. files with format definitions (even partial) I can imagine 'default' file there doing the same job for the default format set but I just could be missing something which is not apparent from changelog ;-) jirka -- 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: [PATCH 20/41] perf tools: Let a user specify a PMU event without any config terms
On Mon, Sep 01, 2014 at 09:27:17AM +0300, Adrian Hunter wrote: > On 08/30/2014 11:53 AM, Jiri Olsa wrote: > > On Fri, Aug 29, 2014 at 09:48:51PM +0300, Adrian Hunter wrote: > >> On 16/07/2014 9:22 p.m., Jiri Olsa wrote: > >>> On Wed, Jul 16, 2014 at 06:04:44PM +0300, Adrian Hunter wrote: > On 16/07/2014 5:25 p.m., Jiri Olsa wrote: > > On Mon, Jul 14, 2014 at 01:02:44PM +0300, Adrian Hunter wrote: > >> This enables a PMU event to be specified in the form: > >> > >>pmu// > >> > >> which is effectively the same as: > >> > >>pmu/config=0/ > >> > >> This patch is a precursor to defining > >> default config for a PMU. > > > > I understand the need for default config, but could you please elaborate > > why do we want to parse 'pmu//' as an event string string? > > Currently the parser requires the slashes to identify a PMU event > as opposed to a hardware or other kind of event. > >>> > >>> right, so why do we want to parse 'pmu//' as an event string? ;-) > >> > >> I am not sure what you mean. Here I am using 'pmu' as a placeholder > >> for a real PMU name. So actual event strings are 'intel_bts//' or > >> 'intel_pt//' or 'intel_pt/tsc=0,noretcomp=1/' > > > > so the consequence of default arguments is that you can > > specify event just by the pmu name, like: > > -e intel_pt// > > > > which means (with default attributes): > > -e intel_pt/tsc=1,noretcomp=0/ > > > > I guess I wanted to hear more elaboration why is this better > > than the current way we have by defining an alias, like: > > > > krava alias: "tsc=1,noretcomp=0" > > > > -e intel_pt/krava/ > > > > which gives the same result > > The default value must be provided by perf tools not the kernel e.g. > an older version of perf tools will not be aware of new hardware > features that the kernel may know about. If the kernel enables > new features by default then the tool may fail. Thus the default > value has to be under the control of the tools not the kernel, so > a sysfs alias will not work. > I dont follow, could u provide some example? why the tool needs to understand.. it will just take the alias and apply/use it? The alias follows the format logic, which tells how to apply values on perf_event_attr.. and the kernel knows best what's supported in its version.. jirka -- 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: [PATCH 20/41] perf tools: Let a user specify a PMU event without any config terms
Em Sat, Aug 30, 2014 at 10:53:10AM +0200, Jiri Olsa escreveu: > On Fri, Aug 29, 2014 at 09:48:51PM +0300, Adrian Hunter wrote: > > On 16/07/2014 9:22 p.m., Jiri Olsa wrote: > > >On Wed, Jul 16, 2014 at 06:04:44PM +0300, Adrian Hunter wrote: > > >>On 16/07/2014 5:25 p.m., Jiri Olsa wrote: > > >>>On Mon, Jul 14, 2014 at 01:02:44PM +0300, Adrian Hunter wrote: > > This enables a PMU event to be specified in the form: > > pmu// > > which is effectively the same as: > > pmu/config=0/ > > This patch is a precursor to defining > > default config for a PMU. > > >>>I understand the need for default config, but could you please elaborate > > >>>why do we want to parse 'pmu//' as an event string string? > > >>Currently the parser requires the slashes to identify a PMU event > > >>as opposed to a hardware or other kind of event. > > >right, so why do we want to parse 'pmu//' as an event string? ;-) > > I am not sure what you mean. Here I am using 'pmu' as a placeholder > > for a real PMU name. So actual event strings are 'intel_bts//' or > > 'intel_pt//' or 'intel_pt/tsc=0,noretcomp=1/' > so the consequence of default arguments is that you can > specify event just by the pmu name, like: > -e intel_pt// > which means (with default attributes): > -e intel_pt/tsc=1,noretcomp=0/ > I guess I wanted to hear more elaboration why is this better > than the current way we have by defining an alias, like: > krava alias: "tsc=1,noretcomp=0" > -e intel_pt/krava/ > which gives the same result So you propose that we start maintaining some table of aliases that would be installed by default, etc? "krava" would not be a good name, I think (:-)), so in this case we would have something like: defaults_intel_pt: "tsc=1,noretcomp=0" -e intel_pt/defaults_intel_pt/ Which of course gets redundant/long, so, using what Adrian suggests, we would instead not pass anything between the slashes, and that would mean "default_" concatenated with the name of the PMU used, so it would become: -e intel_pt// that would be equivalent to: -e intel_pt/defaults_intel_pt/ and also to: -e intel_pt/tsc=1,noretcomp=0/ ? I have not looked at the implementation, this is all just from the information I skimmed in this thread. - Arnaldo -- 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: [PATCH 20/41] perf tools: Let a user specify a PMU event without any config terms
On 08/30/2014 11:53 AM, Jiri Olsa wrote: > On Fri, Aug 29, 2014 at 09:48:51PM +0300, Adrian Hunter wrote: >> On 16/07/2014 9:22 p.m., Jiri Olsa wrote: >>> On Wed, Jul 16, 2014 at 06:04:44PM +0300, Adrian Hunter wrote: On 16/07/2014 5:25 p.m., Jiri Olsa wrote: > On Mon, Jul 14, 2014 at 01:02:44PM +0300, Adrian Hunter wrote: >> This enables a PMU event to be specified in the form: >> >> pmu// >> >> which is effectively the same as: >> >> pmu/config=0/ >> >> This patch is a precursor to defining >> default config for a PMU. > > I understand the need for default config, but could you please elaborate > why do we want to parse 'pmu//' as an event string string? Currently the parser requires the slashes to identify a PMU event as opposed to a hardware or other kind of event. >>> >>> right, so why do we want to parse 'pmu//' as an event string? ;-) >> >> I am not sure what you mean. Here I am using 'pmu' as a placeholder >> for a real PMU name. So actual event strings are 'intel_bts//' or >> 'intel_pt//' or 'intel_pt/tsc=0,noretcomp=1/' > > so the consequence of default arguments is that you can > specify event just by the pmu name, like: > -e intel_pt// > > which means (with default attributes): > -e intel_pt/tsc=1,noretcomp=0/ > > I guess I wanted to hear more elaboration why is this better > than the current way we have by defining an alias, like: > > krava alias: "tsc=1,noretcomp=0" > > -e intel_pt/krava/ > > which gives the same result The default value must be provided by perf tools not the kernel e.g. an older version of perf tools will not be aware of new hardware features that the kernel may know about. If the kernel enables new features by default then the tool may fail. Thus the default value has to be under the control of the tools not the kernel, so a sysfs alias will not work. -- 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: [PATCH 20/41] perf tools: Let a user specify a PMU event without any config terms
On 08/30/2014 11:53 AM, Jiri Olsa wrote: On Fri, Aug 29, 2014 at 09:48:51PM +0300, Adrian Hunter wrote: On 16/07/2014 9:22 p.m., Jiri Olsa wrote: On Wed, Jul 16, 2014 at 06:04:44PM +0300, Adrian Hunter wrote: On 16/07/2014 5:25 p.m., Jiri Olsa wrote: On Mon, Jul 14, 2014 at 01:02:44PM +0300, Adrian Hunter wrote: This enables a PMU event to be specified in the form: pmu// which is effectively the same as: pmu/config=0/ This patch is a precursor to defining default config for a PMU. I understand the need for default config, but could you please elaborate why do we want to parse 'pmu//' as an event string string? Currently the parser requires the slashes to identify a PMU event as opposed to a hardware or other kind of event. right, so why do we want to parse 'pmu//' as an event string? ;-) I am not sure what you mean. Here I am using 'pmu' as a placeholder for a real PMU name. So actual event strings are 'intel_bts//' or 'intel_pt//' or 'intel_pt/tsc=0,noretcomp=1/' so the consequence of default arguments is that you can specify event just by the pmu name, like: -e intel_pt// which means (with default attributes): -e intel_pt/tsc=1,noretcomp=0/ I guess I wanted to hear more elaboration why is this better than the current way we have by defining an alias, like: krava alias: tsc=1,noretcomp=0 -e intel_pt/krava/ which gives the same result The default value must be provided by perf tools not the kernel e.g. an older version of perf tools will not be aware of new hardware features that the kernel may know about. If the kernel enables new features by default then the tool may fail. Thus the default value has to be under the control of the tools not the kernel, so a sysfs alias will not work. -- 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: [PATCH 20/41] perf tools: Let a user specify a PMU event without any config terms
Em Sat, Aug 30, 2014 at 10:53:10AM +0200, Jiri Olsa escreveu: On Fri, Aug 29, 2014 at 09:48:51PM +0300, Adrian Hunter wrote: On 16/07/2014 9:22 p.m., Jiri Olsa wrote: On Wed, Jul 16, 2014 at 06:04:44PM +0300, Adrian Hunter wrote: On 16/07/2014 5:25 p.m., Jiri Olsa wrote: On Mon, Jul 14, 2014 at 01:02:44PM +0300, Adrian Hunter wrote: This enables a PMU event to be specified in the form: pmu// which is effectively the same as: pmu/config=0/ This patch is a precursor to defining default config for a PMU. I understand the need for default config, but could you please elaborate why do we want to parse 'pmu//' as an event string string? Currently the parser requires the slashes to identify a PMU event as opposed to a hardware or other kind of event. right, so why do we want to parse 'pmu//' as an event string? ;-) I am not sure what you mean. Here I am using 'pmu' as a placeholder for a real PMU name. So actual event strings are 'intel_bts//' or 'intel_pt//' or 'intel_pt/tsc=0,noretcomp=1/' so the consequence of default arguments is that you can specify event just by the pmu name, like: -e intel_pt// which means (with default attributes): -e intel_pt/tsc=1,noretcomp=0/ I guess I wanted to hear more elaboration why is this better than the current way we have by defining an alias, like: krava alias: tsc=1,noretcomp=0 -e intel_pt/krava/ which gives the same result So you propose that we start maintaining some table of aliases that would be installed by default, etc? krava would not be a good name, I think (:-)), so in this case we would have something like: defaults_intel_pt: tsc=1,noretcomp=0 -e intel_pt/defaults_intel_pt/ Which of course gets redundant/long, so, using what Adrian suggests, we would instead not pass anything between the slashes, and that would mean default_ concatenated with the name of the PMU used, so it would become: -e intel_pt// that would be equivalent to: -e intel_pt/defaults_intel_pt/ and also to: -e intel_pt/tsc=1,noretcomp=0/ ? I have not looked at the implementation, this is all just from the information I skimmed in this thread. - Arnaldo -- 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: [PATCH 20/41] perf tools: Let a user specify a PMU event without any config terms
On Mon, Sep 01, 2014 at 09:27:17AM +0300, Adrian Hunter wrote: On 08/30/2014 11:53 AM, Jiri Olsa wrote: On Fri, Aug 29, 2014 at 09:48:51PM +0300, Adrian Hunter wrote: On 16/07/2014 9:22 p.m., Jiri Olsa wrote: On Wed, Jul 16, 2014 at 06:04:44PM +0300, Adrian Hunter wrote: On 16/07/2014 5:25 p.m., Jiri Olsa wrote: On Mon, Jul 14, 2014 at 01:02:44PM +0300, Adrian Hunter wrote: This enables a PMU event to be specified in the form: pmu// which is effectively the same as: pmu/config=0/ This patch is a precursor to defining default config for a PMU. I understand the need for default config, but could you please elaborate why do we want to parse 'pmu//' as an event string string? Currently the parser requires the slashes to identify a PMU event as opposed to a hardware or other kind of event. right, so why do we want to parse 'pmu//' as an event string? ;-) I am not sure what you mean. Here I am using 'pmu' as a placeholder for a real PMU name. So actual event strings are 'intel_bts//' or 'intel_pt//' or 'intel_pt/tsc=0,noretcomp=1/' so the consequence of default arguments is that you can specify event just by the pmu name, like: -e intel_pt// which means (with default attributes): -e intel_pt/tsc=1,noretcomp=0/ I guess I wanted to hear more elaboration why is this better than the current way we have by defining an alias, like: krava alias: tsc=1,noretcomp=0 -e intel_pt/krava/ which gives the same result The default value must be provided by perf tools not the kernel e.g. an older version of perf tools will not be aware of new hardware features that the kernel may know about. If the kernel enables new features by default then the tool may fail. Thus the default value has to be under the control of the tools not the kernel, so a sysfs alias will not work. I dont follow, could u provide some example? why the tool needs to understand.. it will just take the alias and apply/use it? The alias follows the format logic, which tells how to apply values on perf_event_attr.. and the kernel knows best what's supported in its version.. jirka -- 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: [PATCH 20/41] perf tools: Let a user specify a PMU event without any config terms
On Mon, Sep 01, 2014 at 12:51:42PM -0300, Arnaldo Carvalho de Melo wrote: SNIP krava alias: tsc=1,noretcomp=0 -e intel_pt/krava/ which gives the same result So you propose that we start maintaining some table of aliases that would be installed by default, etc? krava would not be a good name, I think (:-)), so in this case we would have something like: defaults_intel_pt: tsc=1,noretcomp=0 -e intel_pt/defaults_intel_pt/ Which of course gets redundant/long, so, using what Adrian suggests, we would instead not pass anything between the slashes, and that would mean default_ concatenated with the name of the PMU used, so it would become: -e intel_pt// that would be equivalent to: -e intel_pt/defaults_intel_pt/ and also to: -e intel_pt/tsc=1,noretcomp=0/ ? I have not looked at the implementation, this is all just from the information I skimmed in this thread. well I meant that we already have following directory: /sys/devices/cpu/events for aliases.. files with format definitions (even partial) I can imagine 'default' file there doing the same job for the default format set but I just could be missing something which is not apparent from changelog ;-) jirka -- 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: [PATCH 20/41] perf tools: Let a user specify a PMU event without any config terms
On 09/01/2014 10:11 PM, Jiri Olsa wrote: On Mon, Sep 01, 2014 at 09:27:17AM +0300, Adrian Hunter wrote: On 08/30/2014 11:53 AM, Jiri Olsa wrote: On Fri, Aug 29, 2014 at 09:48:51PM +0300, Adrian Hunter wrote: On 16/07/2014 9:22 p.m., Jiri Olsa wrote: On Wed, Jul 16, 2014 at 06:04:44PM +0300, Adrian Hunter wrote: On 16/07/2014 5:25 p.m., Jiri Olsa wrote: On Mon, Jul 14, 2014 at 01:02:44PM +0300, Adrian Hunter wrote: This enables a PMU event to be specified in the form: pmu// which is effectively the same as: pmu/config=0/ This patch is a precursor to defining default config for a PMU. I understand the need for default config, but could you please elaborate why do we want to parse 'pmu//' as an event string string? Currently the parser requires the slashes to identify a PMU event as opposed to a hardware or other kind of event. right, so why do we want to parse 'pmu//' as an event string? ;-) I am not sure what you mean. Here I am using 'pmu' as a placeholder for a real PMU name. So actual event strings are 'intel_bts//' or 'intel_pt//' or 'intel_pt/tsc=0,noretcomp=1/' so the consequence of default arguments is that you can specify event just by the pmu name, like: -e intel_pt// which means (with default attributes): -e intel_pt/tsc=1,noretcomp=0/ I guess I wanted to hear more elaboration why is this better than the current way we have by defining an alias, like: krava alias: tsc=1,noretcomp=0 -e intel_pt/krava/ which gives the same result The default value must be provided by perf tools not the kernel e.g. an older version of perf tools will not be aware of new hardware features that the kernel may know about. If the kernel enables new features by default then the tool may fail. Thus the default value has to be under the control of the tools not the kernel, so a sysfs alias will not work. I dont follow, could u provide some example? Imagine that the 'tsc' term did not exist. Intel PT trace data would not contain TSC packets, and the decoder would not know how to decode them. Then imagine that a new version of the hardware adds 'tsc'. It is such a useful feature that we want it by default, but older versions of the tools don't know how to decode it, so the kernel cannot turn it on by default. why the tool needs to understand.. it will just take the alias and apply/use it? The alias follows the format logic, which tells how to apply values on perf_event_attr.. and the kernel knows best what's supported in its version.. It is similar to why the kernel does not select mmap2 by default. The kernel doesn't know whether the tool supports it. -- 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: [PATCH 20/41] perf tools: Let a user specify a PMU event without any config terms
On Fri, Aug 29, 2014 at 09:48:51PM +0300, Adrian Hunter wrote: > On 16/07/2014 9:22 p.m., Jiri Olsa wrote: > >On Wed, Jul 16, 2014 at 06:04:44PM +0300, Adrian Hunter wrote: > >>On 16/07/2014 5:25 p.m., Jiri Olsa wrote: > >>>On Mon, Jul 14, 2014 at 01:02:44PM +0300, Adrian Hunter wrote: > This enables a PMU event to be specified in the form: > > pmu// > > which is effectively the same as: > > pmu/config=0/ > > This patch is a precursor to defining > default config for a PMU. > >>> > >>>I understand the need for default config, but could you please elaborate > >>>why do we want to parse 'pmu//' as an event string string? > >> > >>Currently the parser requires the slashes to identify a PMU event > >>as opposed to a hardware or other kind of event. > > > >right, so why do we want to parse 'pmu//' as an event string? ;-) > > I am not sure what you mean. Here I am using 'pmu' as a placeholder > for a real PMU name. So actual event strings are 'intel_bts//' or > 'intel_pt//' or 'intel_pt/tsc=0,noretcomp=1/' so the consequence of default arguments is that you can specify event just by the pmu name, like: -e intel_pt// which means (with default attributes): -e intel_pt/tsc=1,noretcomp=0/ I guess I wanted to hear more elaboration why is this better than the current way we have by defining an alias, like: krava alias: "tsc=1,noretcomp=0" -e intel_pt/krava/ which gives the same result thanks, jirka -- 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: [PATCH 20/41] perf tools: Let a user specify a PMU event without any config terms
On Fri, Aug 29, 2014 at 09:48:51PM +0300, Adrian Hunter wrote: On 16/07/2014 9:22 p.m., Jiri Olsa wrote: On Wed, Jul 16, 2014 at 06:04:44PM +0300, Adrian Hunter wrote: On 16/07/2014 5:25 p.m., Jiri Olsa wrote: On Mon, Jul 14, 2014 at 01:02:44PM +0300, Adrian Hunter wrote: This enables a PMU event to be specified in the form: pmu// which is effectively the same as: pmu/config=0/ This patch is a precursor to defining default config for a PMU. I understand the need for default config, but could you please elaborate why do we want to parse 'pmu//' as an event string string? Currently the parser requires the slashes to identify a PMU event as opposed to a hardware or other kind of event. right, so why do we want to parse 'pmu//' as an event string? ;-) I am not sure what you mean. Here I am using 'pmu' as a placeholder for a real PMU name. So actual event strings are 'intel_bts//' or 'intel_pt//' or 'intel_pt/tsc=0,noretcomp=1/' so the consequence of default arguments is that you can specify event just by the pmu name, like: -e intel_pt// which means (with default attributes): -e intel_pt/tsc=1,noretcomp=0/ I guess I wanted to hear more elaboration why is this better than the current way we have by defining an alias, like: krava alias: tsc=1,noretcomp=0 -e intel_pt/krava/ which gives the same result thanks, jirka -- 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: [PATCH 20/41] perf tools: Let a user specify a PMU event without any config terms
On 16/07/2014 9:22 p.m., Jiri Olsa wrote: On Wed, Jul 16, 2014 at 06:04:44PM +0300, Adrian Hunter wrote: On 16/07/2014 5:25 p.m., Jiri Olsa wrote: On Mon, Jul 14, 2014 at 01:02:44PM +0300, Adrian Hunter wrote: This enables a PMU event to be specified in the form: pmu// which is effectively the same as: pmu/config=0/ This patch is a precursor to defining default config for a PMU. I understand the need for default config, but could you please elaborate why do we want to parse 'pmu//' as an event string string? Currently the parser requires the slashes to identify a PMU event as opposed to a hardware or other kind of event. right, so why do we want to parse 'pmu//' as an event string? ;-) I am not sure what you mean. Here I am using 'pmu' as a placeholder for a real PMU name. So actual event strings are 'intel_bts//' or 'intel_pt//' or 'intel_pt/tsc=0,noretcomp=1/' The parser uses various tricks to decide what kind of event the event name actually is e.g. colons indicate a tracepoint. If you are asking why the parser isn't smart enough to know the event name is a PMU name, I guess it is either to keep the namespaces separate, or because it was easier to program it that way. -- 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: [PATCH 20/41] perf tools: Let a user specify a PMU event without any config terms
On 16/07/2014 9:22 p.m., Jiri Olsa wrote: On Wed, Jul 16, 2014 at 06:04:44PM +0300, Adrian Hunter wrote: On 16/07/2014 5:25 p.m., Jiri Olsa wrote: On Mon, Jul 14, 2014 at 01:02:44PM +0300, Adrian Hunter wrote: This enables a PMU event to be specified in the form: pmu// which is effectively the same as: pmu/config=0/ This patch is a precursor to defining default config for a PMU. I understand the need for default config, but could you please elaborate why do we want to parse 'pmu//' as an event string string? Currently the parser requires the slashes to identify a PMU event as opposed to a hardware or other kind of event. right, so why do we want to parse 'pmu//' as an event string? ;-) I am not sure what you mean. Here I am using 'pmu' as a placeholder for a real PMU name. So actual event strings are 'intel_bts//' or 'intel_pt//' or 'intel_pt/tsc=0,noretcomp=1/' The parser uses various tricks to decide what kind of event the event name actually is e.g. colons indicate a tracepoint. If you are asking why the parser isn't smart enough to know the event name is a PMU name, I guess it is either to keep the namespaces separate, or because it was easier to program it that way. -- 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: [PATCH 20/41] perf tools: Let a user specify a PMU event without any config terms
On Wed, Jul 16, 2014 at 06:04:44PM +0300, Adrian Hunter wrote: > On 16/07/2014 5:25 p.m., Jiri Olsa wrote: > >On Mon, Jul 14, 2014 at 01:02:44PM +0300, Adrian Hunter wrote: > >>This enables a PMU event to be specified in the form: > >> > >>pmu// > >> > >>which is effectively the same as: > >> > >>pmu/config=0/ > >> > >>This patch is a precursor to defining > >>default config for a PMU. > > > >I understand the need for default config, but could you please elaborate > >why do we want to parse 'pmu//' as an event string string? > > Currently the parser requires the slashes to identify a PMU event > as opposed to a hardware or other kind of event. right, so why do we want to parse 'pmu//' as an event string? ;-) jirka -- 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: [PATCH 20/41] perf tools: Let a user specify a PMU event without any config terms
On 16/07/2014 5:25 p.m., Jiri Olsa wrote: On Mon, Jul 14, 2014 at 01:02:44PM +0300, Adrian Hunter wrote: This enables a PMU event to be specified in the form: pmu// which is effectively the same as: pmu/config=0/ This patch is a precursor to defining default config for a PMU. I understand the need for default config, but could you please elaborate why do we want to parse 'pmu//' as an event string string? Currently the parser requires the slashes to identify a PMU event as opposed to a hardware or other kind of event. -- 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: [PATCH 20/41] perf tools: Let a user specify a PMU event without any config terms
On Mon, Jul 14, 2014 at 01:02:44PM +0300, Adrian Hunter wrote: > This enables a PMU event to be specified in the form: > > pmu// > > which is effectively the same as: > > pmu/config=0/ > > This patch is a precursor to defining > default config for a PMU. I understand the need for default config, but could you please elaborate why do we want to parse 'pmu//' as an event string string? thanks, jirka -- 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: [PATCH 20/41] perf tools: Let a user specify a PMU event without any config terms
On Mon, Jul 14, 2014 at 01:02:44PM +0300, Adrian Hunter wrote: This enables a PMU event to be specified in the form: pmu// which is effectively the same as: pmu/config=0/ This patch is a precursor to defining default config for a PMU. I understand the need for default config, but could you please elaborate why do we want to parse 'pmu//' as an event string string? thanks, jirka -- 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: [PATCH 20/41] perf tools: Let a user specify a PMU event without any config terms
On 16/07/2014 5:25 p.m., Jiri Olsa wrote: On Mon, Jul 14, 2014 at 01:02:44PM +0300, Adrian Hunter wrote: This enables a PMU event to be specified in the form: pmu// which is effectively the same as: pmu/config=0/ This patch is a precursor to defining default config for a PMU. I understand the need for default config, but could you please elaborate why do we want to parse 'pmu//' as an event string string? Currently the parser requires the slashes to identify a PMU event as opposed to a hardware or other kind of event. -- 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: [PATCH 20/41] perf tools: Let a user specify a PMU event without any config terms
On Wed, Jul 16, 2014 at 06:04:44PM +0300, Adrian Hunter wrote: On 16/07/2014 5:25 p.m., Jiri Olsa wrote: On Mon, Jul 14, 2014 at 01:02:44PM +0300, Adrian Hunter wrote: This enables a PMU event to be specified in the form: pmu// which is effectively the same as: pmu/config=0/ This patch is a precursor to defining default config for a PMU. I understand the need for default config, but could you please elaborate why do we want to parse 'pmu//' as an event string string? Currently the parser requires the slashes to identify a PMU event as opposed to a hardware or other kind of event. right, so why do we want to parse 'pmu//' as an event string? ;-) jirka -- 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/
[PATCH 20/41] perf tools: Let a user specify a PMU event without any config terms
This enables a PMU event to be specified in the form:
pmu//
which is effectively the same as:
pmu/config=0/
This patch is a precursor to defining
default config for a PMU.
Signed-off-by: Adrian Hunter
---
tools/perf/util/parse-events.c | 6 ++
tools/perf/util/parse-events.y | 10 ++
2 files changed, 16 insertions(+)
diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index 1e15df1..76fd04b 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -644,6 +644,12 @@ int parse_events_add_pmu(struct list_head *list, int *idx,
memset(, 0, sizeof(attr));
+ if (!head_config) {
+ attr.type = pmu->type;
+ evsel = __add_event(list, idx, , NULL, pmu->cpus);
+ return evsel ? 0 : -ENOMEM;
+ }
+
if (perf_pmu__check_alias(pmu, head_config, , ))
return -EINVAL;
diff --git a/tools/perf/util/parse-events.y b/tools/perf/util/parse-events.y
index 0bc87ba..55fab6a 100644
--- a/tools/perf/util/parse-events.y
+++ b/tools/perf/util/parse-events.y
@@ -210,6 +210,16 @@ PE_NAME '/' event_config '/'
parse_events__free_terms($3);
$$ = list;
}
+|
+PE_NAME '/' '/'
+{
+ struct parse_events_evlist *data = _data;
+ struct list_head *list;
+
+ ALLOC_LIST(list);
+ ABORT_ON(parse_events_add_pmu(list, >idx, $1, NULL));
+ $$ = list;
+}
value_sym:
PE_VALUE_SYM_HW
--
1.8.3.2
--
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/
[PATCH 20/41] perf tools: Let a user specify a PMU event without any config terms
This enables a PMU event to be specified in the form:
pmu//
which is effectively the same as:
pmu/config=0/
This patch is a precursor to defining
default config for a PMU.
Signed-off-by: Adrian Hunter adrian.hun...@intel.com
---
tools/perf/util/parse-events.c | 6 ++
tools/perf/util/parse-events.y | 10 ++
2 files changed, 16 insertions(+)
diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index 1e15df1..76fd04b 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -644,6 +644,12 @@ int parse_events_add_pmu(struct list_head *list, int *idx,
memset(attr, 0, sizeof(attr));
+ if (!head_config) {
+ attr.type = pmu-type;
+ evsel = __add_event(list, idx, attr, NULL, pmu-cpus);
+ return evsel ? 0 : -ENOMEM;
+ }
+
if (perf_pmu__check_alias(pmu, head_config, unit, scale))
return -EINVAL;
diff --git a/tools/perf/util/parse-events.y b/tools/perf/util/parse-events.y
index 0bc87ba..55fab6a 100644
--- a/tools/perf/util/parse-events.y
+++ b/tools/perf/util/parse-events.y
@@ -210,6 +210,16 @@ PE_NAME '/' event_config '/'
parse_events__free_terms($3);
$$ = list;
}
+|
+PE_NAME '/' '/'
+{
+ struct parse_events_evlist *data = _data;
+ struct list_head *list;
+
+ ALLOC_LIST(list);
+ ABORT_ON(parse_events_add_pmu(list, data-idx, $1, NULL));
+ $$ = list;
+}
value_sym:
PE_VALUE_SYM_HW
--
1.8.3.2
--
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/
