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

Groups > linux.kernel > #1341650 > unrolled thread

[PATCH 14/15] perf x86 intel: Add DATALA events into sysfs

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

  [PATCH 14/15] perf x86 intel: Add DATALA events into sysfs Jiri Olsa <jolsa@kernel.org> - 2016-02-24 09:50 +0100
    Re: [PATCH 14/15] perf x86 intel: Add DATALA events into sysfs Andi Kleen <ak@linux.intel.com> - 2016-02-24 17:00 +0100
      Re: [PATCH 14/15] perf x86 intel: Add DATALA events into sysfs Jiri Olsa <jolsa@redhat.com> - 2016-02-24 20:00 +0100

#1341650 — [PATCH 14/15] perf x86 intel: Add DATALA events into sysfs

Adding DATALA events into Haaswell events sysfs
directory, so it's easier to use them.

Adding all DATALA events as specified by Intel SDM
manual 18.10.3 PEBS Data Address Profiling.

Link: http://lkml.kernel.org/n/tip-dvpk5ys80v41oh5xgqvloviw@git.kernel.org
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
---
 arch/x86/events/intel/core.c | 39 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 39 insertions(+)

diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
index a7ec685657a5..199f645aedc1 100644
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -3253,6 +3253,26 @@ static __init void intel_ht_bug(void)
 EVENT_ATTR_STR(mem-loads,	mem_ld_hsw,	"event=0xcd,umask=0x1,ldlat=3");
 EVENT_ATTR_STR(mem-stores,	mem_st_hsw,	"event=0xd0,umask=0x82")
 
+EVENT_ATTR_STR(mem-stlb-miss-loads,	hsw_stlb_miss_loads,	"event=0xd0,umask=0x11");
+EVENT_ATTR_STR(mem-stlb-miss-stores,	hsw_stlb_miss_stores,	"event=0xd0,umask=0x12");
+EVENT_ATTR_STR(mem-lock-loads,		hsw_lock_loads,		"event=0xd0,umask=0x21");
+EVENT_ATTR_STR(mem-split-loads,		hsw_split_loads,	"event=0xd0,umask=0x41");
+EVENT_ATTR_STR(mem-split-stores,	hsw_split_stores,	"event=0xd0,umask=0x42");
+EVENT_ATTR_STR(mem-all-loads,		hsw_all_loads,		"event=0xd0,umask=0x81");
+EVENT_ATTR_STR(mem-all-stores,		hsw_all_stores,		"event=0xd0,umask=0x82");
+EVENT_ATTR_STR(mem-load-l1-hit,		hsw_load_l1_hit,	"event=0xd1,umask=0x01");
+EVENT_ATTR_STR(mem-load-l2-hit,		hsw_load_l2_hit,	"event=0xd1,umask=0x02");
+EVENT_ATTR_STR(mem-load-l3-hit,		hsw_load_l3_hit,	"event=0xd1,umask=0x04");
+EVENT_ATTR_STR(mem-load-l1-miss,	hsw_load_l1_miss,	"event=0xd1,umask=0x08");
+EVENT_ATTR_STR(mem-load-l2-miss,	hsw_load_l2_miss,	"event=0xd1,umask=0x10");
+EVENT_ATTR_STR(mem-load-l3-miss,	hsw_load_l3_miss,	"event=0xd1,umask=0x20");
+EVENT_ATTR_STR(mem-load-hit-lfb,	hsw_load_hit_lfb,	"event=0xd1,umask=0x40");
+EVENT_ATTR_STR(mem-snp-miss,		hsw_snp_miss,		"event=0xd2,umask=0x01");
+EVENT_ATTR_STR(mem-snp-hit,		hsw_snp_hit,		"event=0xd2,umask=0x02");
+EVENT_ATTR_STR(mem-snp-hitm,		hsw_snp_hitm,		"event=0xd2,umask=0x04");
+EVENT_ATTR_STR(mem-snp-none,		hsw_snp_none,		"event=0xd2,umask=0x08");
+EVENT_ATTR_STR(mem-local-dram,		hsw_local_dram,		"event=0xd3,umask=0x01");
+
 /* Haswell special events */
 EVENT_ATTR_STR(tx-start,	tx_start,	"event=0xc9,umask=0x1");
 EVENT_ATTR_STR(tx-commit,	tx_commit,	"event=0xc9,umask=0x2");
@@ -3282,6 +3302,25 @@ static struct attribute *hsw_events_attrs[] = {
 	EVENT_PTR(cycles_ct),
 	EVENT_PTR(mem_ld_hsw),
 	EVENT_PTR(mem_st_hsw),
+	EVENT_PTR(hsw_stlb_miss_loads),
+	EVENT_PTR(hsw_stlb_miss_stores),
+	EVENT_PTR(hsw_lock_loads),
+	EVENT_PTR(hsw_split_loads),
+	EVENT_PTR(hsw_split_stores),
+	EVENT_PTR(hsw_all_loads),
+	EVENT_PTR(hsw_all_stores),
+	EVENT_PTR(hsw_load_l1_hit),
+	EVENT_PTR(hsw_load_l2_hit),
+	EVENT_PTR(hsw_load_l3_hit),
+	EVENT_PTR(hsw_load_l1_miss),
+	EVENT_PTR(hsw_load_l2_miss),
+	EVENT_PTR(hsw_load_l3_miss),
+	EVENT_PTR(hsw_load_hit_lfb),
+	EVENT_PTR(hsw_snp_miss),
+	EVENT_PTR(hsw_snp_hit),
+	EVENT_PTR(hsw_snp_hitm),
+	EVENT_PTR(hsw_snp_none),
+	EVENT_PTR(hsw_local_dram),
 	NULL
 };
 
-- 
2.4.3

[toc] | [next] | [standalone]

#1342146

On Wed, Feb 24, 2016 at 09:46:55AM +0100, Jiri Olsa wrote:
> Adding DATALA events into Haaswell events sysfs
> directory, so it's easier to use them.
> 
> Adding all DATALA events as specified by Intel SDM
> manual 18.10.3 PEBS Data Address Profiling.
> 
> Link: http://lkml.kernel.org/n/tip-dvpk5ys80v41oh5xgqvloviw@git.kernel.org
> Signed-off-by: Jiri Olsa <jolsa@kernel.org>
> ---
>  arch/x86/events/intel/core.c | 39 +++++++++++++++++++++++++++++++++++++++
>  1 file changed, 39 insertions(+)
> 
> diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
> index a7ec685657a5..199f645aedc1 100644
> --- a/arch/x86/events/intel/core.c
> +++ b/arch/x86/events/intel/core.c
> @@ -3253,6 +3253,26 @@ static __init void intel_ht_bug(void)
>  EVENT_ATTR_STR(mem-loads,	mem_ld_hsw,	"event=0xcd,umask=0x1,ldlat=3");
>  EVENT_ATTR_STR(mem-stores,	mem_st_hsw,	"event=0xd0,umask=0x82")

> +EVENT_ATTR_STR(mem-load-hit-lfb,	hsw_load_hit_lfb,	"event=0xd1,umask=0x40");
> +EVENT_ATTR_STR(mem-snp-miss,		hsw_snp_miss,		"event=0xd2,umask=0x01");
> +EVENT_ATTR_STR(mem-snp-hit,		hsw_snp_hit,		"event=0xd2,umask=0x02");
> +EVENT_ATTR_STR(mem-snp-hitm,		hsw_snp_hitm,		"event=0xd2,umask=0x04");
> +EVENT_ATTR_STR(mem-snp-none,		hsw_snp_none,		"event=0xd2,umask=0x08");

I don't think these are well enough defined for generic events. For example what does
hit-lfb mean generally? Snooping is also a fairly nebulous concept that can change
between micro architectures.

Instead of adding more and more badly defined and not really portable 
generic events I think it would be better to apply the patches that enable
the full Intel/POWER/other JSON event lists.

They have been posted multiple times by Sukadev and just need to be reviewed,
and would be a far better solution to this.

That would also make them "easy to use".

This would have the advantage that we actually have documentation 
what they actually mean in the SDM, and they map to the
documentation, and people can understand them without needing
to reverse engineer perf.

Also these events can have bugs (see e.g. the Haswell Server spec updates)
and if you can't look them up it can be hard to use.

-Andi

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

#1342340

On Wed, Feb 24, 2016 at 07:59:05AM -0800, Andi Kleen wrote:
> On Wed, Feb 24, 2016 at 09:46:55AM +0100, Jiri Olsa wrote:
> > Adding DATALA events into Haaswell events sysfs
> > directory, so it's easier to use them.
> > 
> > Adding all DATALA events as specified by Intel SDM
> > manual 18.10.3 PEBS Data Address Profiling.
> > 
> > Link: http://lkml.kernel.org/n/tip-dvpk5ys80v41oh5xgqvloviw@git.kernel.org
> > Signed-off-by: Jiri Olsa <jolsa@kernel.org>
> > ---
> >  arch/x86/events/intel/core.c | 39 +++++++++++++++++++++++++++++++++++++++
> >  1 file changed, 39 insertions(+)
> > 
> > diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
> > index a7ec685657a5..199f645aedc1 100644
> > --- a/arch/x86/events/intel/core.c
> > +++ b/arch/x86/events/intel/core.c
> > @@ -3253,6 +3253,26 @@ static __init void intel_ht_bug(void)
> >  EVENT_ATTR_STR(mem-loads,	mem_ld_hsw,	"event=0xcd,umask=0x1,ldlat=3");
> >  EVENT_ATTR_STR(mem-stores,	mem_st_hsw,	"event=0xd0,umask=0x82")
> 
> > +EVENT_ATTR_STR(mem-load-hit-lfb,	hsw_load_hit_lfb,	"event=0xd1,umask=0x40");
> > +EVENT_ATTR_STR(mem-snp-miss,		hsw_snp_miss,		"event=0xd2,umask=0x01");
> > +EVENT_ATTR_STR(mem-snp-hit,		hsw_snp_hit,		"event=0xd2,umask=0x02");
> > +EVENT_ATTR_STR(mem-snp-hitm,		hsw_snp_hitm,		"event=0xd2,umask=0x04");
> > +EVENT_ATTR_STR(mem-snp-none,		hsw_snp_none,		"event=0xd2,umask=0x08");
> 
> I don't think these are well enough defined for generic events. For example what does
> hit-lfb mean generally? Snooping is also a fairly nebulous concept that can change
> between micro architectures.
> 
> Instead of adding more and more badly defined and not really portable 
> generic events I think it would be better to apply the patches that enable
> the full Intel/POWER/other JSON event lists.
> 
> They have been posted multiple times by Sukadev and just need to be reviewed,
> and would be a far better solution to this.
> 
> That would also make them "easy to use".
> 
> This would have the advantage that we actually have documentation 
> what they actually mean in the SDM, and they map to the
> documentation, and people can understand them without needing
> to reverse engineer perf.
> 
> Also these events can have bugs (see e.g. the Haswell Server spec updates)
> and if you can't look them up it can be hard to use.

right, I'll keep that only in my queue.. we discussed with Peter
and he said he'll try to check on JSON patchset state ;-)

thanks,
jirka

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web