Re: [perfmon2] Westmere ACPI vs. NUMA

[stephane eranian <eranian@go...>]

Hi,

Just drop the patch that change the routing if it conflicts for you.
Everything else should still work.


On Mon, Mar 28, 2011 at 1:41 PM, Zoltán Majó <zoltan.majo@...> wrote:
> Hi Stephane,
>
>
> in your last commit
>
> a1d22713bcee9fa384fe3c7a09dbce7f1ddc4f6d
>
> to the perfmon2 kernel tree you changed the Intel Westmere interrupt
> routing. Because of this change it is not possible to use
> CONFIG_HOTPLUG_CPU. However, this variable is enabled if the kernel is
> configured with ACPI.
>
> I would like to do some measurements in a 2-processor Westmere-based
> NUMA system. For my measurements I need NUMA-awareness in Linux.
> However, Linux can get information about the NUMA topology of the
> machine only if ACPI is enabled. In conclusion, it seems that I can
> either have NUMA, or perfmon2, but not both at the same time.
>
> I need only per-core event for my measurements, and not the uncore
> events targeted by your latest patch. Do you think that if I use the
> second last version
>
> 0e3ee97afaaccc932224be1a53625e4da599d7b5
>
> of the perfmon2 kernel, I'll still get correct results for per-core events?
>
> Thanks,
>
>
> Zoltan Majo
>
>
> ------------------------------------------------------------------------------
> Enable your software for Intel(R) Active Management Technology to meet the
> growing manageability and security demands of your customers. Businesses
> are taking advantage of Intel(R) vPro (TM) technology - will your software
> be a part of the solution? Download the Intel(R) Manageability Checker
> today! http://p.sf.net/sfu/intel-dev2devmar
> _______________________________________________
> perfmon2-devel mailing list
> perfmon2-devel@...
> https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
>

[perfmon2] Westmere ACPI vs. NUMA

[Zoltán Majó <zoltan.majo@in...>]

Hi Stephane,


in your last commit

a1d22713bcee9fa384fe3c7a09dbce7f1ddc4f6d

to the perfmon2 kernel tree you changed the Intel Westmere interrupt 
routing. Because of this change it is not possible to use 
CONFIG_HOTPLUG_CPU. However, this variable is enabled if the kernel is 
configured with ACPI.

I would like to do some measurements in a 2-processor Westmere-based 
NUMA system. For my measurements I need NUMA-awareness in Linux. 
However, Linux can get information about the NUMA topology of the 
machine only if ACPI is enabled. In conclusion, it seems that I can 
either have NUMA, or perfmon2, but not both at the same time.

I need only per-core event for my measurements, and not the uncore 
events targeted by your latest patch. Do you think that if I use the 
second last version

0e3ee97afaaccc932224be1a53625e4da599d7b5

of the perfmon2 kernel, I'll still get correct results for per-core events?

Thanks,


Zoltan Majo

Re: [perfmon2] Question about event "BRANCH_INSTRUCTIONS_RETIRED" on x86 machine

[stephane eranian <eranian@go...>]

2011/3/22 陳韋任 <chenwj@...>:
> Hi,
>
>> I doubt this is the problem.
>
> Yeah, I have tried -1 through 2. But none of them works. :/
>
>> You need to make sure you have a kernel that supports PEBS.
>> To do that, you can check the syslog. dmesg | fgrep PEBS should
>> do it.
>
> $ dmesg | grep "Performance Events"
> Performance Events: PEBS fmt0+, Core2 events, Intel PMU driver.
>
>> libbpfm4 does maintain this information. It won't let you enable
>> precise sampling (precise=) if the event does not support PEBS.
>
> `showevtinfo` list events with field Flags, some events'Flags are
> "[precise]". Does this mean those events support PBES? For example,
>
> #-----------------------------
> IDX      : 23068780
> PMU name : core (Intel Core)
> Name     : X87_OPS_RETIRED
> Equiv    : None
> Flags    : [precise]
> Desc     : FXCH instructions retired
> Code     : 0xc1
> Umask-00 : 0x01 : PMU : [FXCH] : None : FXCH instructions retired
> Umask-01 : 0xfe : PMU : [ANY] : [default] [precise] : Retired floating-point computational operations (Precise Event)
> Modif-00 : 0x00 : PMU : [k] : monitor at priv level 0 (boolean)
> Modif-01 : 0x01 : PMU : [u] : monitor at priv level 1, 2, 3 (boolean)
> Modif-02 : 0x02 : PMU : [e] : edge level (boolean)
> Modif-03 : 0x03 : PMU : [i] : invert (boolean)
> Modif-04 : 0x04 : PMU : [c] : counter-mask in range [0-255] (integer)
>
> $ evt2raw -v X87_OPS_RETIRED:FXCH
> r5301c1 core::X87_OPS_RETIRED:FXCH:e=0:i=0:c=0:u=1:k=1:precise=0
> $ evt2raw -v X87_OPS_RETIRED:FXCH:precise=1
> r5301c1 core::X87_OPS_RETIRED:FXCH:e=0:i=0:c=0:u=1:k=1:precise=1
>
> $ ./perf_examples/evt2raw -v X87_OPS_RETIRED
> r53fec1 core::X87_OPS_RETIRED:ANY:e=0:i=0:c=0:u=1:k=1:precise=0
> $ ./perf_examples/evt2raw -v X87_OPS_RETIRED:precise=1
> r53fec1 core::X87_OPS_RETIRED:ANY:e=0:i=0:c=0:u=1:k=1:precise=1
>
>  Here are some questions,
>
> 1. From the output of `showevtinfo`, one might think X87_OPS_RETIRED:FXCH
>   does not allow PBES compared with X87_OPS_RETIRED:ANY. But `evt2raw`
>   does not reject this kind input. Is this a bug? Or I just
>   misunderstood what `showevtinfo` output means?
>
evt2raw does not take into account the precise attribute. That's
because it does not
impact attr->config but rather attr->precise_ip.

> 2. Assume X87_OPS_RETIRED:ANY allows "precise=0" or "precise=1". But the
>   raw event code are the same (r53fec1). Is this right? If so, how does
>   `perf` choose to use PBES or not?
>
precise=0 -> do not use PEBS
precise=1 -> use PEBS but do not try to correct IP+1 skid
precise=2 -> use PEBS + LBR to correct IP+1 skid

Again PEBS does not impact event code.

Use task_smpl to check if this event actually work as PEBS. If so it should
capture samples marked with '(exact)' when precise=2.

>  Thanks!
>
> Regards,
> chenwj
>
> --
> Wei-Ren Chen (陳韋任)
> Parallel Processing Lab, Institute of Information Science,
> Academia Sinica, Taiwan (R.O.C.)
> Tel:886-2-2788-3799 #1667
>

Re: [perfmon2] Question about event "BRANCH_INSTRUCTIONS_RETIRED" on x86 machine

[陳韋任 <chenwj@ii...>]

Hi, Stephane

> > $ dmesg | grep "Performance Events"
> > Performance Events: PEBS fmt0+, Core2 events, Intel PMU driver.
> >
> On Core 2 due to a PMU erratum on cetain models, PEBS is disabled
> at boot time. This is true if you have a model 15 CPU.

  Model 15 CPU? I can only guess what you said can be found in
/proc/cpuinfo. If so, I think it's not a model 15 CPU.

vendor_id       : GenuineIntel
cpu family      : 6
model           : 23
model name      : Intel(R) Xeon(R) CPU           E5410  @ 2.33GHz

Regards,
chenwj

-- 
Wei-Ren Chen (陳韋任)
Parallel Processing Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667

Re: [perfmon2] Question about event "BRANCH_INSTRUCTIONS_RETIRED" on x86 machine

[stephane eranian <eranian@go...>]

2011/3/22 陳韋任 <chenwj@...>:
> Hi,
>
>> I doubt this is the problem.
>
> Yeah, I have tried -1 through 2. But none of them works. :/
>
>> You need to make sure you have a kernel that supports PEBS.
>> To do that, you can check the syslog. dmesg | fgrep PEBS should
>> do it.
>
> $ dmesg | grep "Performance Events"
> Performance Events: PEBS fmt0+, Core2 events, Intel PMU driver.
>
On Core 2 due to a PMU erratum on cetain models, PEBS is disabled
at boot time. This is true if you have a model 15 CPU.

>> libbpfm4 does maintain this information. It won't let you enable
>> precise sampling (precise=) if the event does not support PEBS.
>
> `showevtinfo` list events with field Flags, some events'Flags are
> "[precise]". Does this mean those events support PBES? For example,
>
> #-----------------------------
> IDX      : 23068780
> PMU name : core (Intel Core)
> Name     : X87_OPS_RETIRED
> Equiv    : None
> Flags    : [precise]
> Desc     : FXCH instructions retired
> Code     : 0xc1
> Umask-00 : 0x01 : PMU : [FXCH] : None : FXCH instructions retired
> Umask-01 : 0xfe : PMU : [ANY] : [default] [precise] : Retired floating-point computational operations (Precise Event)
> Modif-00 : 0x00 : PMU : [k] : monitor at priv level 0 (boolean)
> Modif-01 : 0x01 : PMU : [u] : monitor at priv level 1, 2, 3 (boolean)
> Modif-02 : 0x02 : PMU : [e] : edge level (boolean)
> Modif-03 : 0x03 : PMU : [i] : invert (boolean)
> Modif-04 : 0x04 : PMU : [c] : counter-mask in range [0-255] (integer)
>
> $ evt2raw -v X87_OPS_RETIRED:FXCH
> r5301c1 core::X87_OPS_RETIRED:FXCH:e=0:i=0:c=0:u=1:k=1:precise=0
> $ evt2raw -v X87_OPS_RETIRED:FXCH:precise=1
> r5301c1 core::X87_OPS_RETIRED:FXCH:e=0:i=0:c=0:u=1:k=1:precise=1
>
> $ ./perf_examples/evt2raw -v X87_OPS_RETIRED
> r53fec1 core::X87_OPS_RETIRED:ANY:e=0:i=0:c=0:u=1:k=1:precise=0
> $ ./perf_examples/evt2raw -v X87_OPS_RETIRED:precise=1
> r53fec1 core::X87_OPS_RETIRED:ANY:e=0:i=0:c=0:u=1:k=1:precise=1
>
>  Here are some questions,
>
> 1. From the output of `showevtinfo`, one might think X87_OPS_RETIRED:FXCH
>   does not allow PBES compared with X87_OPS_RETIRED:ANY. But `evt2raw`
>   does not reject this kind input. Is this a bug? Or I just
>   misunderstood what `showevtinfo` output means?
>
> 2. Assume X87_OPS_RETIRED:ANY allows "precise=0" or "precise=1". But the
>   raw event code are the same (r53fec1). Is this right? If so, how does
>   `perf` choose to use PBES or not?
>
>  Thanks!
>
> Regards,
> chenwj
>
> --
> Wei-Ren Chen (陳韋任)
> Parallel Processing Lab, Institute of Information Science,
> Academia Sinica, Taiwan (R.O.C.)
> Tel:886-2-2788-3799 #1667
>

[perfmon2] [PATCH] perf_events: fix cgrp stale pointer in update_cgrp_time_from_cpuctx() v2

[Stephane Eranian <eranian@go...>]

This patch solves a stale pointer problem in
update_cgrp_time_from_cpuctx(). The cpuctx->cgrp
was not cleared on all possible event exit paths,
including:
   close()
     perf_release()
       perf_release_kernel()
         list_del_event()

This patch fixes list_del_event() to clear cpuctx->cgrp
when there are no cgroup events left in the context.

This second version makes the code compile when CONFIG_CGROUP_PERF
is not enabled. We unconditionally define perf_cpu_context->cgrp.

Signed-off-by: Stephane Eranian <eranian@...>
---

diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index f495c01..311b4dc 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -938,9 +938,7 @@ struct perf_cpu_context {
 	struct list_head		rotation_list;
 	int				jiffies_interval;
 	struct pmu			*active_pmu;
-#ifdef CONFIG_CGROUP_PERF
 	struct perf_cgroup		*cgrp;
-#endif
 };
 
 struct perf_output_handle {
diff --git a/kernel/perf_event.c b/kernel/perf_event.c
index 3472bb1..0c71422 100644
--- a/kernel/perf_event.c
+++ b/kernel/perf_event.c
@@ -941,6 +941,7 @@ static void perf_group_attach(struct perf_event *event)
 static void
 list_del_event(struct perf_event *event, struct perf_event_context *ctx)
 {
+	struct perf_cpu_context *cpuctx;
 	/*
 	 * We can have double detach due to exit/hot-unplug + close.
 	 */
@@ -949,8 +950,17 @@ list_del_event(struct perf_event *event, struct perf_event_context *ctx)
 
 	event->attach_state &= ~PERF_ATTACH_CONTEXT;
 
-	if (is_cgroup_event(event))
+	if (is_cgroup_event(event)) {
 		ctx->nr_cgroups--;
+		cpuctx = __get_cpu_context(ctx);
+		/*
+		 * if there are no more cgroup events
+		 * then cler cgrp to avoid stale pointer
+		 * in update_cgrp_time_from_cpuctx()
+		 */
+		if (!ctx->nr_cgroups)
+			cpuctx->cgrp = NULL;
+	}
 
 	ctx->nr_events--;
 	if (event->attr.inherit_stat)

Re: [perfmon2] [PATCH] perf_events: fix cgrp stale pointer in update_cgrp_time_from_cpuctx()

[Stephane Eranian <eranian@go...>]

On Wed, Mar 23, 2011 at 12:36 PM, Ingo Molnar <mingo@...> wrote:
>
> * Stephane Eranian <eranian@...> wrote:
>
>> -     if (is_cgroup_event(event))
>> +     if (is_cgroup_event(event)) {
>>               ctx->nr_cgroups--;
>> +             cpuctx = __get_cpu_context(ctx);
>> +             /*
>> +              * if there are no more cgroup events
>> +              * then clear cgrp to avoid stale pointer
>> +              * in update_cgrp_time_from_cpuctx()
>> +              */
>> +             if (!ctx->nr_cgroups)
>> +                     cpuctx->cgrp = NULL;
>> +     }
>
> The ->cgrp pointer does not exist on !CGROUPS kernels. I suspect the cleanest
> approach would be to make those two cgrp fields available unconditionally in
> struct perf_event.
>
Argh, I forgot to test !CGROUP.
I tend to agree with you on making those fields unconditional. We
don't save that
much by not doing it.

> Thanks,
>
>        Ingo
>

Re: [perfmon2] [PATCH] perf_events: fix cgrp stale pointer in update_cgrp_time_from_cpuctx()

[Ingo Molnar <mingo@el...>]

* Stephane Eranian <eranian@...> wrote:

> -	if (is_cgroup_event(event))
> +	if (is_cgroup_event(event)) {
>  		ctx->nr_cgroups--;
> +		cpuctx = __get_cpu_context(ctx);
> +		/*
> +		 * if there are no more cgroup events
> +		 * then clear cgrp to avoid stale pointer
> +		 * in update_cgrp_time_from_cpuctx()
> +		 */
> +		if (!ctx->nr_cgroups)
> +			cpuctx->cgrp = NULL;
> +	}

The ->cgrp pointer does not exist on !CGROUPS kernels. I suspect the cleanest 
approach would be to make those two cgrp fields available unconditionally in 
struct perf_event.

Thanks,

	Ingo

[perfmon2] [PATCH] Teach perf script about PERF_TYPE_RAW

[Arun Sharma <asharma@fb...>]

Useful for getting stack traces for hardware events not handled
by PERF_TYPE_HARDWARE.

Signed-off-by: Arun Sharma <asharma@...>
Cc: Ingo Molnar <mingo@...>
Cc: Frederic Weisbecker <fweisbec@...>
Cc: Mike Galbraith <efault@...>
Cc: Paul Mackerras <paulus@...>
Cc: Peter Zijlstra <a.p.zijlstra@...>
Cc: Stephane Eranian <eranian@...>
Cc: Thomas Gleixner <tglx@...>
Cc: Tom Zanussi <tzanussi@...>
Cc: linux-kernel@...
Cc: linux-perf-users@...
Cc: perfmon2-devel@...
---
 tools/perf/builtin-script.c |    8 +++++++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index 9f5fc54..97c66df 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -61,6 +61,10 @@ static u64 output_fields[PERF_TYPE_MAX] = {
 	[PERF_TYPE_TRACEPOINT] = PERF_OUTPUT_COMM | PERF_OUTPUT_TID | \
 				 PERF_OUTPUT_CPU | PERF_OUTPUT_TIME | \
 				 PERF_OUTPUT_EVNAME | PERF_OUTPUT_TRACE,
+
+	[PERF_TYPE_RAW] = PERF_OUTPUT_COMM | PERF_OUTPUT_TID | \
+			  PERF_OUTPUT_CPU | PERF_OUTPUT_TIME | \
+			  PERF_OUTPUT_EVNAME | PERF_OUTPUT_SYM,
 };
 
 static bool output_set_by_user;
@@ -481,6 +485,8 @@ static int parse_output_fields(const struct option *opt __used,
 		type = PERF_TYPE_SOFTWARE;
 	else if (!strcmp(tok, "trace"))
 		type = PERF_TYPE_TRACEPOINT;
+	else if (!strcmp(tok, "raw"))
+		type = PERF_TYPE_RAW;
 	else {
 		fprintf(stderr, "Invalid event type in field string.");
 		return -EINVAL;
@@ -836,7 +842,7 @@ static const struct option options[] = {
 	OPT_STRING(0, "symfs", &symbol_conf.symfs, "directory",
 		    "Look for files with symbols relative to this directory"),
 	OPT_CALLBACK('f', "fields", NULL, "str",
-		     "comma separated output fields prepend with 'type:'. Valid types: hw,sw,trace. Fields: comm,tid,pid,time,cpu,event,trace,sym",
+		     "comma separated output fields prepend with 'type:'. Valid types: hw,sw,trace,raw. Fields: comm,tid,pid,time,cpu,event,trace,sym",
 		     parse_output_fields),
 
 	OPT_END()
-- 
1.7.4

Re: [perfmon2] libpfm4 and AMD Bobcat processors

[Rahul Garg <rahulgarg44@gm...>]

Great! Thanks.

rahul

On Tue, Mar 22, 2011 at 6:03 PM, stephane eranian <eranian@...>wrote:

> Rahul,
>
> At first glance, looks like the 2.6.35 kernel would work on Family 14h.
> So you're just missing the libpfm4 support, which should not be too
> difficult to add. Looks like fam14h is very close fam10h.
>
>
> On Tue, Mar 22, 2011 at 10:52 PM, Rahul Garg <rahulgarg44@...>
> wrote:
> > Ok thanks for the info. I am a little unclear about the kernel. Will I
> need
> > to update the kernel to newer version to use libpfm4 with this processor
> > (when the support is available in libpfm4)? I was hoping to use 2.6.35
> due
> > to other constraints.
> > Thanks for all your work! Have been a happy user of libpfm on other
> > processors.
> > rahul
> > On Tue, Mar 22, 2011 at 5:44 PM, stephane eranian <
> eranian@...>
> > wrote:
> >>
> >> Looks like the BKDG just came out a few days ago:
> >>
> >> http://support.amd.com/us/Processor_TechDocs/43170.pdf
> >>
> >> Need to look into the PMU description.
> >>
> >> Also note that beyond libpfm4, the kernel would need to be updated
> >> to support Fam14h.
> >>
> >>
> >> On Tue, Mar 22, 2011 at 10:41 PM, stephane eranian
> >> <eranian@...> wrote:
> >> > Hi,
> >> >
> >> > Is the spec of Fam 14h available?
> >> >
> >> >
> >> > On Tue, Mar 22, 2011 at 10:37 PM, Rahul Garg <rahulgarg44@...>
> >> > wrote:
> >> >> Hi.
> >> >>
> >> >> Bobcat is AMD Family 14h. Some products based on it include AMD E-350
> >> >> Fusion
> >> >> APU, E-240 APU and C-50 APU etc.
> >> >>
> >> >>
> >> >> rahul
> >> >>
> >> >> On Tue, Mar 22, 2011 at 5:26 PM, stephane eranian
> >> >> <eranian@...>
> >> >> wrote:
> >> >>>
> >> >>> Hi,
> >> >>>
> >> >>> On Tue, Mar 22, 2011 at 10:22 PM, Rahul Garg <rahulgarg44@...
> >
> >> >>> wrote:
> >> >>> > Hi everyone.
> >> >>> >
> >> >>> > I was wondering if libpfm4 supports this processor? I don't have a
> >> >>> > machine
> >> >>> > yet so cannot test this myself :(
> >> >>> >
> >> >>> I don't know much about Bobcat. It is unlcear to me whether it is
> >> >>> based on
> >> >>> Family 10h or 15h micro-architecture?
> >> >>>
> >> >>> libpfm4 will supports both. Fam15h is in progres..
> >> >>>
> >> >>> > rahul
> >> >>> >
> >> >>> >
> >> >>> >
> >> >>> >
> ------------------------------------------------------------------------------
> >> >>> > Enable your software for Intel(R) Active Management Technology to
> >> >>> > meet
> >> >>> > the
> >> >>> > growing manageability and security demands of your customers.
> >> >>> > Businesses
> >> >>> > are taking advantage of Intel(R) vPro (TM) technology - will your
> >> >>> > software
> >> >>> > be a part of the solution? Download the Intel(R) Manageability
> >> >>> > Checker
> >> >>> > today! http://p.sf.net/sfu/intel-dev2devmar
> >> >>> > _______________________________________________
> >> >>> > perfmon2-devel mailing list
> >> >>> > perfmon2-devel@...
> >> >>> > https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
> >> >>> >
> >> >>> >
> >> >>
> >> >>
> >> >
> >
> >
>

Re: [perfmon2] libpfm4 and AMD Bobcat processors

[stephane eranian <eranian@go...>]

Rahul,

At first glance, looks like the 2.6.35 kernel would work on Family 14h.
So you're just missing the libpfm4 support, which should not be too
difficult to add. Looks like fam14h is very close fam10h.


On Tue, Mar 22, 2011 at 10:52 PM, Rahul Garg <rahulgarg44@...> wrote:
> Ok thanks for the info. I am a little unclear about the kernel. Will I need
> to update the kernel to newer version to use libpfm4 with this processor
> (when the support is available in libpfm4)? I was hoping to use 2.6.35 due
> to other constraints.
> Thanks for all your work! Have been a happy user of libpfm on other
> processors.
> rahul
> On Tue, Mar 22, 2011 at 5:44 PM, stephane eranian <eranian@...>
> wrote:
>>
>> Looks like the BKDG just came out a few days ago:
>>
>> http://support.amd.com/us/Processor_TechDocs/43170.pdf
>>
>> Need to look into the PMU description.
>>
>> Also note that beyond libpfm4, the kernel would need to be updated
>> to support Fam14h.
>>
>>
>> On Tue, Mar 22, 2011 at 10:41 PM, stephane eranian
>> <eranian@...> wrote:
>> > Hi,
>> >
>> > Is the spec of Fam 14h available?
>> >
>> >
>> > On Tue, Mar 22, 2011 at 10:37 PM, Rahul Garg <rahulgarg44@...>
>> > wrote:
>> >> Hi.
>> >>
>> >> Bobcat is AMD Family 14h. Some products based on it include AMD E-350
>> >> Fusion
>> >> APU, E-240 APU and C-50 APU etc.
>> >>
>> >>
>> >> rahul
>> >>
>> >> On Tue, Mar 22, 2011 at 5:26 PM, stephane eranian
>> >> <eranian@...>
>> >> wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>> On Tue, Mar 22, 2011 at 10:22 PM, Rahul Garg <rahulgarg44@...>
>> >>> wrote:
>> >>> > Hi everyone.
>> >>> >
>> >>> > I was wondering if libpfm4 supports this processor? I don't have a
>> >>> > machine
>> >>> > yet so cannot test this myself :(
>> >>> >
>> >>> I don't know much about Bobcat. It is unlcear to me whether it is
>> >>> based on
>> >>> Family 10h or 15h micro-architecture?
>> >>>
>> >>> libpfm4 will supports both. Fam15h is in progres..
>> >>>
>> >>> > rahul
>> >>> >
>> >>> >
>> >>> >
>> >>> > ------------------------------------------------------------------------------
>> >>> > Enable your software for Intel(R) Active Management Technology to
>> >>> > meet
>> >>> > the
>> >>> > growing manageability and security demands of your customers.
>> >>> > Businesses
>> >>> > are taking advantage of Intel(R) vPro (TM) technology - will your
>> >>> > software
>> >>> > be a part of the solution? Download the Intel(R) Manageability
>> >>> > Checker
>> >>> > today! http://p.sf.net/sfu/intel-dev2devmar
>> >>> > _______________________________________________
>> >>> > perfmon2-devel mailing list
>> >>> > perfmon2-devel@...
>> >>> > https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
>> >>> >
>> >>> >
>> >>
>> >>
>> >
>
>

Re: [perfmon2] libpfm4 and AMD Bobcat processors

[Rahul Garg <rahulgarg44@gm...>]

Ok thanks for the info. I am a little unclear about the kernel. Will I need
to update the kernel to newer version to use libpfm4 with this processor
(when the support is available in libpfm4)? I was hoping to use 2.6.35 due
to other constraints.
Thanks for all your work! Have been a happy user of libpfm on other
processors.

rahul

On Tue, Mar 22, 2011 at 5:44 PM, stephane eranian <eranian@...>wrote:

> Looks like the BKDG just came out a few days ago:
>
> http://support.amd.com/us/Processor_TechDocs/43170.pdf
>
> Need to look into the PMU description.
>
> Also note that beyond libpfm4, the kernel would need to be updated
> to support Fam14h.
>
>
> On Tue, Mar 22, 2011 at 10:41 PM, stephane eranian
> <eranian@...> wrote:
> > Hi,
> >
> > Is the spec of Fam 14h available?
> >
> >
> > On Tue, Mar 22, 2011 at 10:37 PM, Rahul Garg <rahulgarg44@...>
> wrote:
> >> Hi.
> >>
> >> Bobcat is AMD Family 14h. Some products based on it include AMD E-350
> Fusion
> >> APU, E-240 APU and C-50 APU etc.
> >>
> >>
> >> rahul
> >>
> >> On Tue, Mar 22, 2011 at 5:26 PM, stephane eranian <
> eranian@...>
> >> wrote:
> >>>
> >>> Hi,
> >>>
> >>> On Tue, Mar 22, 2011 at 10:22 PM, Rahul Garg <rahulgarg44@...>
> >>> wrote:
> >>> > Hi everyone.
> >>> >
> >>> > I was wondering if libpfm4 supports this processor? I don't have a
> >>> > machine
> >>> > yet so cannot test this myself :(
> >>> >
> >>> I don't know much about Bobcat. It is unlcear to me whether it is based
> on
> >>> Family 10h or 15h micro-architecture?
> >>>
> >>> libpfm4 will supports both. Fam15h is in progres..
> >>>
> >>> > rahul
> >>> >
> >>> >
> >>> >
> ------------------------------------------------------------------------------
> >>> > Enable your software for Intel(R) Active Management Technology to
> meet
> >>> > the
> >>> > growing manageability and security demands of your customers.
> Businesses
> >>> > are taking advantage of Intel(R) vPro (TM) technology - will your
> >>> > software
> >>> > be a part of the solution? Download the Intel(R) Manageability
> Checker
> >>> > today! http://p.sf.net/sfu/intel-dev2devmar
> >>> > _______________________________________________
> >>> > perfmon2-devel mailing list
> >>> > perfmon2-devel@...
> >>> > https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
> >>> >
> >>> >
> >>
> >>
> >
>

Re: [perfmon2] libpfm4 and AMD Bobcat processors

[stephane eranian <eranian@go...>]

Looks like the BKDG just came out a few days ago:

http://support.amd.com/us/Processor_TechDocs/43170.pdf

Need to look into the PMU description.

Also note that beyond libpfm4, the kernel would need to be updated
to support Fam14h.


On Tue, Mar 22, 2011 at 10:41 PM, stephane eranian
<eranian@...> wrote:
> Hi,
>
> Is the spec of Fam 14h available?
>
>
> On Tue, Mar 22, 2011 at 10:37 PM, Rahul Garg <rahulgarg44@...> wrote:
>> Hi.
>>
>> Bobcat is AMD Family 14h. Some products based on it include AMD E-350 Fusion
>> APU, E-240 APU and C-50 APU etc.
>>
>>
>> rahul
>>
>> On Tue, Mar 22, 2011 at 5:26 PM, stephane eranian <eranian@...>
>> wrote:
>>>
>>> Hi,
>>>
>>> On Tue, Mar 22, 2011 at 10:22 PM, Rahul Garg <rahulgarg44@...>
>>> wrote:
>>> > Hi everyone.
>>> >
>>> > I was wondering if libpfm4 supports this processor? I don't have a
>>> > machine
>>> > yet so cannot test this myself :(
>>> >
>>> I don't know much about Bobcat. It is unlcear to me whether it is based on
>>> Family 10h or 15h micro-architecture?
>>>
>>> libpfm4 will supports both. Fam15h is in progres..
>>>
>>> > rahul
>>> >
>>> >
>>> > ------------------------------------------------------------------------------
>>> > Enable your software for Intel(R) Active Management Technology to meet
>>> > the
>>> > growing manageability and security demands of your customers. Businesses
>>> > are taking advantage of Intel(R) vPro (TM) technology - will your
>>> > software
>>> > be a part of the solution? Download the Intel(R) Manageability Checker
>>> > today! http://p.sf.net/sfu/intel-dev2devmar
>>> > _______________________________________________
>>> > perfmon2-devel mailing list
>>> > perfmon2-devel@...
>>> > https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
>>> >
>>> >
>>
>>
>

Re: [perfmon2] libpfm4 and AMD Bobcat processors

[stephane eranian <eranian@go...>]

Hi,

Is the spec of Fam 14h available?


On Tue, Mar 22, 2011 at 10:37 PM, Rahul Garg <rahulgarg44@...> wrote:
> Hi.
>
> Bobcat is AMD Family 14h. Some products based on it include AMD E-350 Fusion
> APU, E-240 APU and C-50 APU etc.
>
>
> rahul
>
> On Tue, Mar 22, 2011 at 5:26 PM, stephane eranian <eranian@...>
> wrote:
>>
>> Hi,
>>
>> On Tue, Mar 22, 2011 at 10:22 PM, Rahul Garg <rahulgarg44@...>
>> wrote:
>> > Hi everyone.
>> >
>> > I was wondering if libpfm4 supports this processor? I don't have a
>> > machine
>> > yet so cannot test this myself :(
>> >
>> I don't know much about Bobcat. It is unlcear to me whether it is based on
>> Family 10h or 15h micro-architecture?
>>
>> libpfm4 will supports both. Fam15h is in progres..
>>
>> > rahul
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Enable your software for Intel(R) Active Management Technology to meet
>> > the
>> > growing manageability and security demands of your customers. Businesses
>> > are taking advantage of Intel(R) vPro (TM) technology - will your
>> > software
>> > be a part of the solution? Download the Intel(R) Manageability Checker
>> > today! http://p.sf.net/sfu/intel-dev2devmar
>> > _______________________________________________
>> > perfmon2-devel mailing list
>> > perfmon2-devel@...
>> > https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
>> >
>> >
>
>

Re: [perfmon2] libpfm4 and AMD Bobcat processors

[Rahul Garg <rahulgarg44@gm...>]

Hi.

Bobcat is AMD Family 14h. Some products based on it include AMD E-350 Fusion
APU, E-240 APU and C-50 APU etc.


rahul

On Tue, Mar 22, 2011 at 5:26 PM, stephane eranian <eranian@...>wrote:

> Hi,
>
> On Tue, Mar 22, 2011 at 10:22 PM, Rahul Garg <rahulgarg44@...>
> wrote:
> > Hi everyone.
> >
> > I was wondering if libpfm4 supports this processor? I don't have a
> machine
> > yet so cannot test this myself :(
> >
> I don't know much about Bobcat. It is unlcear to me whether it is based on
> Family 10h or 15h micro-architecture?
>
> libpfm4 will supports both. Fam15h is in progres..
>
> > rahul
> >
> >
> ------------------------------------------------------------------------------
> > Enable your software for Intel(R) Active Management Technology to meet
> the
> > growing manageability and security demands of your customers. Businesses
> > are taking advantage of Intel(R) vPro (TM) technology - will your
> software
> > be a part of the solution? Download the Intel(R) Manageability Checker
> > today! http://p.sf.net/sfu/intel-dev2devmar
> > _______________________________________________
> > perfmon2-devel mailing list
> > perfmon2-devel@...
> > https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
> >
> >
>

Re: [perfmon2] libpfm4 and AMD Bobcat processors

[stephane eranian <eranian@go...>]

Hi,

On Tue, Mar 22, 2011 at 10:22 PM, Rahul Garg <rahulgarg44@...> wrote:
> Hi everyone.
>
> I was wondering if libpfm4 supports this processor? I don't have a machine
> yet so cannot test this myself :(
>
I don't know much about Bobcat. It is unlcear to me whether it is based on
Family 10h or 15h micro-architecture?

libpfm4 will supports both. Fam15h is in progres..

> rahul
>
> ------------------------------------------------------------------------------
> Enable your software for Intel(R) Active Management Technology to meet the
> growing manageability and security demands of your customers. Businesses
> are taking advantage of Intel(R) vPro (TM) technology - will your software
> be a part of the solution? Download the Intel(R) Manageability Checker
> today! http://p.sf.net/sfu/intel-dev2devmar
> _______________________________________________
> perfmon2-devel mailing list
> perfmon2-devel@...
> https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
>
>

[perfmon2] libpfm4 and AMD Bobcat processors

[Rahul Garg <rahulgarg44@gm...>]

Hi everyone.

I was wondering if libpfm4 supports this processor? I don't have a machine
yet so cannot test this myself :(

rahul

Re: [perfmon2] Question about event "BRANCH_INSTRUCTIONS_RETIRED" on x86 machine

[陳韋任 <chenwj@ii...>]

Hi,

> I doubt this is the problem.

Yeah, I have tried -1 through 2. But none of them works. :/
 
> You need to make sure you have a kernel that supports PEBS.
> To do that, you can check the syslog. dmesg | fgrep PEBS should
> do it.

$ dmesg | grep "Performance Events"
Performance Events: PEBS fmt0+, Core2 events, Intel PMU driver.
 
> libbpfm4 does maintain this information. It won't let you enable
> precise sampling (precise=) if the event does not support PEBS.

`showevtinfo` list events with field Flags, some events'Flags are
"[precise]". Does this mean those events support PBES? For example,

#-----------------------------
IDX      : 23068780
PMU name : core (Intel Core)
Name     : X87_OPS_RETIRED
Equiv    : None
Flags    : [precise]
Desc     : FXCH instructions retired
Code     : 0xc1
Umask-00 : 0x01 : PMU : [FXCH] : None : FXCH instructions retired
Umask-01 : 0xfe : PMU : [ANY] : [default] [precise] : Retired floating-point computational operations (Precise Event)
Modif-00 : 0x00 : PMU : [k] : monitor at priv level 0 (boolean)
Modif-01 : 0x01 : PMU : [u] : monitor at priv level 1, 2, 3 (boolean)
Modif-02 : 0x02 : PMU : [e] : edge level (boolean)
Modif-03 : 0x03 : PMU : [i] : invert (boolean)
Modif-04 : 0x04 : PMU : [c] : counter-mask in range [0-255] (integer)

$ evt2raw -v X87_OPS_RETIRED:FXCH
r5301c1 core::X87_OPS_RETIRED:FXCH:e=0:i=0:c=0:u=1:k=1:precise=0
$ evt2raw -v X87_OPS_RETIRED:FXCH:precise=1
r5301c1 core::X87_OPS_RETIRED:FXCH:e=0:i=0:c=0:u=1:k=1:precise=1

$ ./perf_examples/evt2raw -v X87_OPS_RETIRED
r53fec1 core::X87_OPS_RETIRED:ANY:e=0:i=0:c=0:u=1:k=1:precise=0
$ ./perf_examples/evt2raw -v X87_OPS_RETIRED:precise=1
r53fec1 core::X87_OPS_RETIRED:ANY:e=0:i=0:c=0:u=1:k=1:precise=1

  Here are some questions,

1. From the output of `showevtinfo`, one might think X87_OPS_RETIRED:FXCH
   does not allow PBES compared with X87_OPS_RETIRED:ANY. But `evt2raw`
   does not reject this kind input. Is this a bug? Or I just
   misunderstood what `showevtinfo` output means?

2. Assume X87_OPS_RETIRED:ANY allows "precise=0" or "precise=1". But the
   raw event code are the same (r53fec1). Is this right? If so, how does
   `perf` choose to use PBES or not?

  Thanks!

Regards,
chenwj

-- 
Wei-Ren Chen (陳韋任)
Parallel Processing Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667

Re: [perfmon2] Question about event "BRANCH_INSTRUCTIONS_RETIRED" on x86 machine

[陳韋任 <chenwj@ii...>]

Hi,

> I suspect so. Older version of perf add poor error messages.
>
> Which machine is this running on?

  The attachments are outputs of dmsg and cpuinfo. Is it possible to
build a newer perf by a "normal" user himself? Or the newer perf needs
a kernel update to work correctly?

  If a newer perf can be build by a normal user without kernel update
and works correctly, I can try a new one myself.

  Thanks.

Regards,
chenwj

-- 
Wei-Ren Chen (陳韋任)
Parallel Processing Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667

[perfmon2] [PATCH] perf_events: fix cgrp stale pointer in update_cgrp_time_from_cpuctx()

[Stephane Eranian <eranian@go...>]

This patch solves a stale pointer problem in
update_cgrp_time_from_cpuctx(). The cpuctx->cgrp
was not cleared on all possible event exit paths,
including:
   close()
     perf_release()
       perf_release_kernel()
         list_del_event()

This patch fixes list_del_event() to clear cpuctx->cgrp
when there are no cgroup events left in the context.

Signed-off-by: Stephane Eranian <eranian@...>
---

diff --git a/kernel/perf_event.c b/kernel/perf_event.c
index 3472bb1..0c71422 100644
--- a/kernel/perf_event.c
+++ b/kernel/perf_event.c
@@ -941,6 +941,7 @@ static void perf_group_attach(struct perf_event *event)
 static void
 list_del_event(struct perf_event *event, struct perf_event_context *ctx)
 {
+	struct perf_cpu_context *cpuctx;
 	/*
 	 * We can have double detach due to exit/hot-unplug + close.
 	 */
@@ -949,8 +950,17 @@ list_del_event(struct perf_event *event, struct perf_event_context *ctx)
 
 	event->attach_state &= ~PERF_ATTACH_CONTEXT;
 
-	if (is_cgroup_event(event))
+	if (is_cgroup_event(event)) {
 		ctx->nr_cgroups--;
+		cpuctx = __get_cpu_context(ctx);
+		/*
+		 * if there are no more cgroup events
+		 * then clear cgrp to avoid stale pointer
+		 * in update_cgrp_time_from_cpuctx()
+		 */
+		if (!ctx->nr_cgroups)
+			cpuctx->cgrp = NULL;
+	}
 
 	ctx->nr_events--;
 	if (event->attr.inherit_stat)

Re: [perfmon2] Question about event "BRANCH_INSTRUCTIONS_RETIRED" on x86 machine

[stephane eranian <eranian@go...>]

On Mon, Mar 21, 2011 at 10:43 AM, 陳韋任 <chenwj@...> wrote:
> Hi,
>
>  Ah, I see. There is a comment at kernel/perf_event.c:
>
> /*
>  * perf event paranoia level:
>  *  -1 - not paranoid at all
>  *   0 - disallow raw tracepoint access for unpriv
>  *   1 - disallow cpu events for unpriv
>  *   2 - disallow kernel profiling for unpriv
>  */
>
I doubt this is the problem.

You need to make sure you have a kernel that supports PEBS.
To do that, you can check the syslog. dmesg | fgrep PEBS should
do it.

>  But I have another question. `perf list` give me no such information
> about PBES, so I have to try and error. Is there a better way to know
> which events can be applied whith modifier "p"?
>
perf list does not give you this information because it does not know.
That is one of the many caveats of generic PMU events. You don't
know on what they are mapped to, thus it is hard to go back to the
PMU documentation to figure out PEBS.

The Intel documentation provides the information as to what event
supports PEBS (precise sampling), though it is known to miss some.

libbpfm4 does maintain this information. It won't let you enable
precise sampling (precise=) if the event does not support PEBS.


> Regards,
> chenwj
>
> --
> Wei-Ren Chen (陳韋任)
> Parallel Processing Lab, Institute of Information Science,
> Academia Sinica, Taiwan (R.O.C.)
> Tel:886-2-2788-3799 #1667
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> perfmon2-devel mailing list
> perfmon2-devel@...
> https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
>

Re: [perfmon2] Question about event "BRANCH_INSTRUCTIONS_RETIRED" on x86 machine

[stephane eranian <eranian@go...>]

On Mon, Mar 21, 2011 at 6:52 AM, 陳韋任 <chenwj@...> wrote:
> Hi,
>
>> Note that not all events support PEBS. This is PMU specific. The kernel
>> rejects any attempts to use PEBS on events which do not support it.
>
> $ perf stat -e branches:pp ls
> No permission to collect stats.
> Consider tweaking /proc/sys/kernel/perf_event_paranoid.
>
I doubt this problem is permission related. It may be that perf is
over-interpreting
the error code.

>  Does above mean event "branches" does not support PBES? Or something
> else?
>
I suspect so. Older version of perf add poor error messages.

Which machine is this running on?

>  Thanks!
>
> Regards,
> chenwj
>
> --
> Wei-Ren Chen (陳韋任)
> Parallel Processing Lab, Institute of Information Science,
> Academia Sinica, Taiwan (R.O.C.)
> Tel:886-2-2788-3799 #1667
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> perfmon2-devel mailing list
> perfmon2-devel@...
> https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
>

Re: [perfmon2] Last Branch Record support?

[stephane eranian <eranian@go...>]

Hi,

On Mon, Mar 21, 2011 at 5:08 AM, Arun Sharma <arun@...> wrote:
> 2011/3/20 陳韋任 <chenwj@...>:
>
>>  And I am wondering is it possible that libpfm4 exposes LBR to users
>> even perf_events doesn't?
>
> No - the kernel needs to support this functionality by exposing it via
> a system call. libpfm4 is a user level convenience library that
> converts an event name into a structure expected by the kernel.
>
Arun is correct. LBR needs to be exposed thru the perf_event_open() system
+ sampling buffer. That's not the case today.


>  -Arun
>

Re: [perfmon2] Question about event "BRANCH_INSTRUCTIONS_RETIRED" on x86 machine

[陳韋任 <chenwj@ii...>]

Hi,

  Ah, I see. There is a comment at kernel/perf_event.c:

/*
 * perf event paranoia level:
 *  -1 - not paranoid at all
 *   0 - disallow raw tracepoint access for unpriv
 *   1 - disallow cpu events for unpriv
 *   2 - disallow kernel profiling for unpriv
 */

  But I have another question. `perf list` give me no such information
about PBES, so I have to try and error. Is there a better way to know
which events can be applied whith modifier "p"?

Regards,
chenwj

-- 
Wei-Ren Chen (陳韋任)
Parallel Processing Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667

Re: [perfmon2] Question about event "BRANCH_INSTRUCTIONS_RETIRED" on x86 machine

[陳韋任 <chenwj@ii...>]

Hi,

> Note that not all events support PEBS. This is PMU specific. The kernel
> rejects any attempts to use PEBS on events which do not support it.

$ perf stat -e branches:pp ls
No permission to collect stats.
Consider tweaking /proc/sys/kernel/perf_event_paranoid.

  Does above mean event "branches" does not support PBES? Or something
else?

  Thanks!

Regards,
chenwj

-- 
Wei-Ren Chen (陳韋任)
Parallel Processing Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667