Re: Intel Goldmont default event

[William Cohen <wcohen@re...>]

On 09/23/2016 01:10 PM, Andi Kleen wrote:
> On Fri, Sep 23, 2016 at 01:35:54PM +0200, Michael Petlan wrote:
>> Hi all,
>>
>> when testing oprofile on an Intel Goldmont machine, I have found out
>> that the default event cpu_clk_unhalted returns always zero. Thus, I
>> checked the configuration and Intel SDM, and I think there must be a
>> mistake.
>>
>> According to the Intel SDM, table 19-24, the event is 0x3c as usual.
>> It has two unit masks (0x00 (core_p) and 0x01 (ref)). With this, the
>> event starts giving reasonable results.
>>
>> The current configuration  which is coded in oprofile is not even in
>> the SDM tale 19-24, so it is expectable that the following will give
>> zero value:
>>
>> perf stat -e cpu/event=0x00,umask=0x02/ ls
>>
>> Please consider applying the attached patch.
> 
> Looks good. Thanks for fixing.
> 
> -Andi
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> oprofile-list mailing list
> oprofile-list@...
> https://lists.sourceforge.net/lists/listinfo/oprofile-list
> 

Thanks Michael and Andi,

The patch for the goldmont default event has been applied to the upstream oprofile.

-Will

Re: Intel Goldmont default event

[Andi Kleen <ak@li...>]

On Fri, Sep 23, 2016 at 01:35:54PM +0200, Michael Petlan wrote:
> Hi all,
> 
> when testing oprofile on an Intel Goldmont machine, I have found out
> that the default event cpu_clk_unhalted returns always zero. Thus, I
> checked the configuration and Intel SDM, and I think there must be a
> mistake.
> 
> According to the Intel SDM, table 19-24, the event is 0x3c as usual.
> It has two unit masks (0x00 (core_p) and 0x01 (ref)). With this, the
> event starts giving reasonable results.
> 
> The current configuration  which is coded in oprofile is not even in
> the SDM tale 19-24, so it is expectable that the following will give
> zero value:
> 
> perf stat -e cpu/event=0x00,umask=0x02/ ls
> 
> Please consider applying the attached patch.

Looks good. Thanks for fixing.

-Andi

Intel Goldmont default event

[Michael Petlan <mpetlan@re...>]

Hi all,

when testing oprofile on an Intel Goldmont machine, I have found out
that the default event cpu_clk_unhalted returns always zero. Thus, I
checked the configuration and Intel SDM, and I think there must be a
mistake.

According to the Intel SDM, table 19-24, the event is 0x3c as usual.
It has two unit masks (0x00 (core_p) and 0x01 (ref)). With this, the
event starts giving reasonable results.

The current configuration  which is coded in oprofile is not even in
the SDM tale 19-24, so it is expectable that the following will give
zero value:

perf stat -e cpu/event=0x00,umask=0x02/ ls

Please consider applying the attached patch.

CC'ing Andi to verify the fix.

Thank you,
Michael

How to make Oprofile ignore the signal SIGSEGV

[Leo Chen. <leo.chen@gm...>]

Hi, all

Normally, my programe use sigaction() to catch the signal SIGSEGV, to do
something about memory reserve/commit (such as mmap()/mprotect() ). The
signal of SIGSEGV is my expected behavior, and it just work fine.

But if I use Oprofile to profile my programe. My programe will abort
immediately and get this error message:
"profiled app killed by signal 11 (SIGSEGV)"

My question is: if I don't change my programe's implementation, how can I
set the Oprofile to ignore the signal SIGSEGV?

[PATCH 09/21] oprofile: timer: Convert to hotplug state machine

[Sebastian Andrzej Siewior <bigeasy@li...>]

Install the callbacks via the state machine and let the core invoke
the callbacks on the already online CPUs.
Since the online target runs always on the target CPU we can drop
smp_call_function_single(). The functions is invoked with interrupts off to
keep the old calling convention. If the maintainer things that this function
can be called with interrupts enabled then it can be removed :)

Cc: Robert Richter <rric@...>
Cc: oprofile-list@...
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@...>
---
 drivers/oprofile/timer_int.c | 44 +++++++++++++++++++++++---------------------
 1 file changed, 23 insertions(+), 21 deletions(-)

diff --git a/drivers/oprofile/timer_int.c b/drivers/oprofile/timer_int.c
index bdef916e5dda..2498a6cd7c24 100644
--- a/drivers/oprofile/timer_int.c
+++ b/drivers/oprofile/timer_int.c
@@ -74,37 +74,39 @@ static void oprofile_hrtimer_stop(void)
 	put_online_cpus();
 }
 
-static int oprofile_cpu_notify(struct notifier_block *self,
-			       unsigned long action, void *hcpu)
+static int oprofile_timer_online(unsigned int cpu)
 {
-	long cpu = (long) hcpu;
-
-	switch (action) {
-	case CPU_ONLINE:
-	case CPU_ONLINE_FROZEN:
-		smp_call_function_single(cpu, __oprofile_hrtimer_start,
-					 NULL, 1);
-		break;
-	case CPU_DEAD:
-	case CPU_DEAD_FROZEN:
-		__oprofile_hrtimer_stop(cpu);
-		break;
-	}
-	return NOTIFY_OK;
+	local_irq_disable();
+	__oprofile_hrtimer_start(NULL);
+	local_irq_enable();
+	return 0;
 }
 
-static struct notifier_block __refdata oprofile_cpu_notifier = {
-	.notifier_call = oprofile_cpu_notify,
-};
+static int oprofile_timer_prep_down(unsigned int cpu)
+{
+	__oprofile_hrtimer_stop(cpu);
+	return 0;
+}
+
+static enum cpuhp_state hp_online;
 
 static int oprofile_hrtimer_setup(void)
 {
-	return register_hotcpu_notifier(&oprofile_cpu_notifier);
+	int ret;
+
+	ret = cpuhp_setup_state_nocalls(CPUHP_AP_ONLINE_DYN,
+					"oprofile/timer:online",
+					oprofile_timer_online,
+					oprofile_timer_prep_down);
+	if (ret < 0)
+		return ret;
+	hp_online = ret;
+	return 0;
 }
 
 static void oprofile_hrtimer_shutdown(void)
 {
-	unregister_hotcpu_notifier(&oprofile_cpu_notifier);
+	cpuhp_remove_state_nocalls(hp_online);
 }
 
 int oprofile_timer_init(struct oprofile_operations *ops)
-- 
2.9.3

Re: [PATCH 2/6] oprofile/x86: add regs->ip to oprofile trace

[Robert Richter <rric@ke...>]

On 24.08.16 11:50:15, Josh Poimboeuf wrote:
> dump_trace() doesn't add the interrupted instruction's address to the
> trace, so add it manually.  This makes the profile more useful, and also
> makes it more consistent with what perf profiling does.
> 
> Cc: Robert Richter <rric@...>
> Signed-off-by: Josh Poimboeuf <jpoimboe@...>
> ---
>  arch/x86/oprofile/backtrace.c | 13 ++++++++++---
>  1 file changed, 10 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/oprofile/backtrace.c b/arch/x86/oprofile/backtrace.c
> index cb31a44..2ef6c8b 100644
> --- a/arch/x86/oprofile/backtrace.c
> +++ b/arch/x86/oprofile/backtrace.c
> @@ -114,9 +114,16 @@ x86_backtrace(struct pt_regs * const regs, unsigned int depth)
>  
>  	if (!user_mode(regs)) {
>  		unsigned long stack = kernel_stack_pointer(regs);
> -		if (depth)
> -			dump_trace(NULL, regs, (unsigned long *)stack, 0,
> -				   &backtrace_ops, &depth);
> +
> +		if (!depth)
> +			return;
> +
> +		oprofile_add_trace(regs->ip);
> +		if (!--depth)
> +			return;
> +
> +		dump_trace(NULL, regs, (unsigned long *)stack, 0,
> +			   &backtrace_ops, &depth);

Acked-by: Robert Richter <rric@...>

Adding oprofile-list in case someone has objections since this may
break userland tools.

Ingo, please apply the patch to tip once this series is ok to you.

Thanks,

-Robert

>  		return;
>  	}
>  
> -- 
> 2.7.4
> 

[PATCH 0813/1285] Replace numeric parameter like 0444 with macro

[Baole Ni <baolex.ni@in...>]

I find that the developers often just specified the numeric value
when calling a macro which is defined with a parameter for access permission.
As we know, these numeric value for access permission have had the corresponding macro,
and that using macro can improve the robustness and readability of the code,
thus, I suggest replacing the numeric parameter with the macro.

Signed-off-by: Chuansheng Liu <chuansheng.liu@...>
Signed-off-by: Baole Ni <baolex.ni@...>
---
 drivers/oprofile/oprof.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/oprofile/oprof.c b/drivers/oprofile/oprof.c
index ed2c3ec..622e370 100644
--- a/drivers/oprofile/oprof.c
+++ b/drivers/oprofile/oprof.c
@@ -278,7 +278,7 @@ static void __exit oprofile_exit(void)
 module_init(oprofile_init);
 module_exit(oprofile_exit);
 
-module_param_named(timer, timer, int, 0644);
+module_param_named(timer, timer, int, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
 MODULE_PARM_DESC(timer, "force use of timer interrupt");
 
 MODULE_LICENSE("GPL");
-- 
2.9.2

[PATCH 14/19] oprofile/x86: convert x86_backtrace() to the new unwinder

[Josh Poimboeuf <jpoimboe@re...>]

Convert oprofile's x86_backtrace() to the new unwinder.  dump_trace()
has been deprecated.

Cc: Robert Richter <rric@...>
Cc: oprofile-list@...
Signed-off-by: Josh Poimboeuf <jpoimboe@...>
---
 arch/x86/oprofile/backtrace.c | 42 +++++++++++++++++++-----------------------
 1 file changed, 19 insertions(+), 23 deletions(-)

diff --git a/arch/x86/oprofile/backtrace.c b/arch/x86/oprofile/backtrace.c
index c594768..6cda1f4 100644
--- a/arch/x86/oprofile/backtrace.c
+++ b/arch/x86/oprofile/backtrace.c
@@ -16,27 +16,7 @@
 
 #include <asm/ptrace.h>
 #include <asm/stacktrace.h>
-
-static int backtrace_stack(void *data, char *name)
-{
-	/* Yes, we want all stacks */
-	return 0;
-}
-
-static int backtrace_address(void *data, unsigned long addr, int reliable)
-{
-	unsigned int *depth = data;
-
-	if ((*depth)--)
-		oprofile_add_trace(addr);
-	return 0;
-}
-
-static struct stacktrace_ops backtrace_ops = {
-	.stack		= backtrace_stack,
-	.address	= backtrace_address,
-	.walk_stack	= print_context_stack,
-};
+#include <asm/unwind.h>
 
 #ifdef CONFIG_COMPAT
 static struct stack_frame_ia32 *
@@ -113,8 +93,24 @@ x86_backtrace(struct pt_regs * const regs, unsigned int depth)
 	struct stack_frame *head = (struct stack_frame *)frame_pointer(regs);
 
 	if (!user_mode(regs)) {
-		if (depth)
-			dump_trace(NULL, regs, NULL, 0, &backtrace_ops, &depth);
+		struct unwind_state state;
+		unsigned long addr;
+
+		if (!depth)
+			return;
+
+		oprofile_add_trace(regs->ip);
+
+		if (!--depth)
+			return;
+
+		for (unwind_start(&state, NULL, regs, NULL);
+		     !unwind_done(&state); unwind_next_frame(&state)) {
+			addr = unwind_get_return_address(&state);
+			oprofile_add_trace(addr);
+			if (!--depth)
+				break;
+		}
 		return;
 	}
 
-- 
2.7.4

RE: oprofile support for PPC_E5500

[Beaman, Thomas <Thomas.B<eaman@xe...>]

> > Hi Tom,
> >
> > as William said, it would be nice to have the WindRiver oprofile patch
> > posted to the oprofile-list and incorporate it into upstream oprofile,
> > in order to eliminate the need of it. Could you please ask someone in
> > WindRiver about it?
> 
> I have filed a request with Windriver to submit their e6500 patch for review,
> and they have responded they will look into it and get back to me. I will let
> you know what they say.
> 
> 

I have received an message back  from Windriver on the oprofile e6500 patch.  You can contact Ray Blackburn at ray.blackburn@... and reference case 00059721. He will be the initial contact.

Tom

[patch V2 50/67] MIPS/Loongson-3: Convert oprofile to hotplug state machine

[Anna-Maria Gleixner <anna-maria@li...>]

From: Richard Cochran <rcochran@...>

Install the callbacks via the state machine and let the core invoke
the callbacks on the already online CPUs.

Signed-off-by: Richard Cochran <rcochran@...>
Reviewed-by: Sebastian Andrzej Siewior <bigeasy@...>
Acked-by: Ralf Baechle <ralf@...>
Cc: Linus Torvalds <torvalds@...>
Cc: Peter Zijlstra <peterz@...>
Cc: Robert Richter <rric@...>
Cc: Thomas Gleixner <tglx@...>
Cc: linux-mips@...
Cc: oprofile-list@...
Signed-off-by: Anna-Maria Gleixner <anna-maria@...>
---
 arch/mips/oprofile/op_model_loongson3.c | 35 +++++++++++++--------------------
 include/linux/cpuhotplug.h              |  1 +
 2 files changed, 15 insertions(+), 21 deletions(-)

diff --git a/arch/mips/oprofile/op_model_loongson3.c b/arch/mips/oprofile/op_model_loongson3.c
index 8bcf7fc..85f3ee4 100644
--- a/arch/mips/oprofile/op_model_loongson3.c
+++ b/arch/mips/oprofile/op_model_loongson3.c
@@ -168,33 +168,26 @@ static int loongson3_perfcount_handler(void)
 	return handled;
 }
 
-static int loongson3_cpu_callback(struct notifier_block *nfb,
-	unsigned long action, void *hcpu)
+static int loongson3_starting_cpu(unsigned int cpu)
 {
-	switch (action) {
-	case CPU_STARTING:
-	case CPU_STARTING_FROZEN:
-		write_c0_perflo1(reg.control1);
-		write_c0_perflo2(reg.control2);
-		break;
-	case CPU_DYING:
-	case CPU_DYING_FROZEN:
-		write_c0_perflo1(0xc0000000);
-		write_c0_perflo2(0x40000000);
-		break;
-	}
-
-	return NOTIFY_OK;
+	write_c0_perflo1(reg.control1);
+	write_c0_perflo2(reg.control2);
+	return 0;
 }
 
-static struct notifier_block loongson3_notifier_block = {
-	.notifier_call = loongson3_cpu_callback
-};
+static int loongson3_dying_cpu(unsigned int cpu)
+{
+	write_c0_perflo1(0xc0000000);
+	write_c0_perflo2(0x40000000);
+	return 0;
+}
 
 static int __init loongson3_init(void)
 {
 	on_each_cpu(reset_counters, NULL, 1);
-	register_hotcpu_notifier(&loongson3_notifier_block);
+	cpuhp_setup_state_nocalls(CPUHP_AP_MIPS_OP_LOONGSON3_STARTING,
+				  "AP_MIPS_OP_LOONGSON3_STARTING",
+				  loongson3_starting_cpu, loongson3_dying_cpu);
 	save_perf_irq = perf_irq;
 	perf_irq = loongson3_perfcount_handler;
 
@@ -204,7 +197,7 @@ static int __init loongson3_init(void)
 static void loongson3_exit(void)
 {
 	on_each_cpu(reset_counters, NULL, 1);
-	unregister_hotcpu_notifier(&loongson3_notifier_block);
+	cpuhp_remove_state_nocalls(CPUHP_AP_MIPS_OP_LOONGSON3_STARTING);
 	perf_irq = save_perf_irq;
 }
 
diff --git a/include/linux/cpuhotplug.h b/include/linux/cpuhotplug.h
index f986963..18dbf7b 100644
--- a/include/linux/cpuhotplug.h
+++ b/include/linux/cpuhotplug.h
@@ -36,6 +36,7 @@ enum cpuhp_state {
 	CPUHP_AP_PERF_X86_CSTATE_STARTING,
 	CPUHP_AP_PERF_XTENSA_STARTING,
 	CPUHP_AP_PERF_METAG_STARTING,
+	CPUHP_AP_MIPS_OP_LOONGSON3_STARTING,
 	CPUHP_AP_ARM_VFP_STARTING,
 	CPUHP_AP_PERF_ARM_STARTING,
 	CPUHP_AP_ARM_L2X0_STARTING,
-- 
2.8.1

RE: oprofile support for PPC_E5500

[Beaman, Thomas <Thomas.B<eaman@xe...>]

> -----Original Message-----
> From: Michael Petlan [mailto:mpetlan@...]
> Sent: Wednesday, July 13, 2016 10:16 AM
> To: Beaman, Thomas
> Cc: William Cohen; oprofile-list@...
> Subject: RE: oprofile support for PPC_E5500
> 
> On Wed, 13 Jul 2016, Beaman, Thomas wrote:
> >
> >>
> >> Since the `perf list` shows stalled-cycles-frontend and
> >> stalled-cycles-backend events, it seems it does not use the
> >> e6500-pmu.c file, since these events are specified in e500-pmu.c only.
> >>
> >> Tom, the question was whether WindRiver has some kernel patches for
> >> e5500 support or not.
> >>
> >> You may also try to see which PMU drivers are present in kallsyms:
> >>
> >> cat /proc/kallsyms | grep pmu | grep init
> >>
> >> If you see e5500 there, your kernel probably has some
> >> WindRiver-specific patch, since there is probably no init_e5500_pmu in
> the upstream kernel.
> >>
> >> Michael
> >
> > Hi Michael,
> >
> > There are no specific WindRiver patches that I can see for the e5500 and
> there is no init_e5500 in kallsyms. How do you think we should proceed ?
> >
> > Thanks,
> > Tom
> >
> > root@...:~# cat /proc/kallsyms | grep pmu | grep init
> > c000000000059de8 t .fsl_emb_pmu_event_init
> > c00000000005acf0 t .init_e500_pmu
> > c00000000005ade4 t .init_e6500_pmu
> > c000000000c51f10 t __initcall_init_e500_pmuearly
> > c000000000c51f18 t __initcall_init_e6500_pmuearly
> > c000000000d3e480 d fsl_emb_pmu_event_init
> > c000000000d3e5b8 d init_e500_pmu
> > c000000000d3e5e8 d init_e6500_pmu
> >
> >
> >
> 
> Hi Tom,
> 
> as William said, it would be nice to have the WindRiver oprofile patch posted
> to the oprofile-list and incorporate it into upstream oprofile, in order to
> eliminate the need of it. Could you please ask someone in WindRiver about
> it?

I have filed a request with Windriver to submit their e6500 patch for review, and they have responded they will look into it and get back to me. I will let you know what they say.

> 
> Then, it would be nice to know the set of events supported by E5500 in order
> to have correct events/ppc64/e5500/events file. In my patch, I supposed
> that it has the same events as e6500, which is not probable. So it might either
> have e500mc's events or it might have its own set.
> 
> Since we don't have the sufficienf knowledge, I am trying to approximate to
> the correct set. For that, I asked you to test the CLK_FPU_DIV against some
> program that performs lots of FPU divisions and L1_CACHE_* events against
> something that might be more cache_stressing than the tested 'sleep 1'
> command. You may use my sample program I use (attached).
> 
> As I wrote in some of the previous e-mails, the following from your
> results.csv looks suspicious:
> 
> DL1_RELOADS,18240,100.00
> IL1_FETCH_RELOADS,11714,100.00
> L1_STASH_HIT,0,100.00
> L1_STASH_REQ,0,100.00
> L1_CACHE_MISSES,0,100.00
> L1_CACHE_LOAD_MISSES,0,100.00
> L1_CACHE_STORE_MISSES,0,100.00
> 
> While DL1_RELOADS and IL1_FETCH_RELOADS events give some non-zero
> results, the L1_CACHE_MISSES, L1_CACHE_LOAD_MISSES and
> L1_CACHE_STORE_MISSES are zero. This is probably wrong. Since the
> L1_CACHE_MISSES event and the LOAD/STORE brothers are e6500-only, I
> guess they are a sign that e5500 cannot have the e6500 event set. You can
> prove this guess by checking whether you are able to get non-zero values
> here with cache-stressing or not.
> 

Sorry I was not able to get you this data sooner, I got tied up in other matters.

I compiled and ran your cache stress program and I think it proved your theory that the e5500 is not the same as the e6500 in this area. The results still show zero on the same L1 entries

./cache_stress 32384
Allocated 1061158912 bytes from addr 0xb8b43008
Doing 100000 memory operations.
Finished 100000 memory operations.

./check_events.sh

grep L1 results.log
DL1_RELOADS,18561,100.00
IL1_FETCH_RELOADS,10777,100.00
L1_STASH_HIT,0,100.00
L1_STASH_REQ,0,100.00
L1_CACHE_MISSES,0,100.00
L1_CACHE_LOAD_MISSES,0,100.00
L1_CACHE_STORE_MISSES,0,100.00
L1_CACHE_IM,0,100.00

Also  (the other L1 events showed the same type of results)

 ocount -e L1_STASH_HIT ./cache_stress 32384
Allocated 1061158912 bytes from addr 0xb8513008
Doing 100000 memory operations.
Finished 100000 memory operations.

Events were actively counted for 662947632 nanoseconds.
Event counts (actual) for /opt/XRX_IOT/miopqt/cache_stress:
        Event                Count                    % time counted
        L1_STASH_HIT         0                        100.00



> Second thing I picked from your results is the CLK_FPU_DIV:
> 
> It should count cycles spent in fdivs or fdiv instructions. So I'd try to test it by
> something like:
> 
> #include <stdio.h>
> #include <stdlib.h>
> int main(int argc, char *argv[])
> {
>  	double a = atof(argv[1]);
>  	double b = 3.14159265;
>  	double c = a / b;
>  	printf("res = %lf\n", c);
>  	return 0;
> }
> 
> gcc -o div -O0 -g div.c
> 
> Check whether it contains the fdif or fdivs instrucions by:
> 
> objdump -d div
> 
> If it contains the instructions, try to get a nonzero result from CLK_FPU_DIV:
> 
> ocount -e CLK_FPU_DIV ./div 23445
> 
> 
> Thanks.
> Michael
> 

objdump shows there is one fdiv instruction in the program

powerpc-wrs-linux-gnu-objdump -d div | grep -i fdiv
10000500:       fc 0d 00 24     fdiv    f0,f13,f0


root@...:miopqt# ocount -e CLK_FPU_DIV ./div 23445
res = 7462.775290

Events were actively counted for 3338854 nanoseconds.
Event counts (actual) for /opt/XRX_IOT/miopqt/div:
        Event               Count                    % time counted
        CLK_FPU_DIV         1                        100.00


Let me know what over data I can help collect.

Thanks for your help on this,
Tom

RE: oprofile support for PPC_E5500

[Michael Petlan <mpetlan@re...>]

On Wed, 13 Jul 2016, Beaman, Thomas wrote:
>
>>
>> Since the `perf list` shows stalled-cycles-frontend and stalled-cycles-backend
>> events, it seems it does not use the e6500-pmu.c file, since these events are
>> specified in e500-pmu.c only.
>>
>> Tom, the question was whether WindRiver has some kernel patches for
>> e5500 support or not.
>>
>> You may also try to see which PMU drivers are present in kallsyms:
>>
>> cat /proc/kallsyms | grep pmu | grep init
>>
>> If you see e5500 there, your kernel probably has some WindRiver-specific
>> patch, since there is probably no init_e5500_pmu in the upstream kernel.
>>
>> Michael
>
> Hi Michael,
>
> There are no specific WindRiver patches that I can see for the e5500 and there is no init_e5500 in kallsyms. How do you think we should proceed ?
>
> Thanks,
> Tom
>
> root@...:~# cat /proc/kallsyms | grep pmu | grep init
> c000000000059de8 t .fsl_emb_pmu_event_init
> c00000000005acf0 t .init_e500_pmu
> c00000000005ade4 t .init_e6500_pmu
> c000000000c51f10 t __initcall_init_e500_pmuearly
> c000000000c51f18 t __initcall_init_e6500_pmuearly
> c000000000d3e480 d fsl_emb_pmu_event_init
> c000000000d3e5b8 d init_e500_pmu
> c000000000d3e5e8 d init_e6500_pmu
>
>
>

Hi Tom,

as William said, it would be nice to have the WindRiver oprofile patch posted
to the oprofile-list and incorporate it into upstream oprofile, in order to
eliminate the need of it. Could you please ask someone in WindRiver about it?

Then, it would be nice to know the set of events supported by E5500 in order to
have correct events/ppc64/e5500/events file. In my patch, I supposed that it has
the same events as e6500, which is not probable. So it might either have e500mc's
events or it might have its own set.

Since we don't have the sufficienf knowledge, I am trying to approximate to the
correct set. For that, I asked you to test the CLK_FPU_DIV against some program
that performs lots of FPU divisions and L1_CACHE_* events against something that
might be more cache_stressing than the tested 'sleep 1' command. You may use my
sample program I use (attached).

As I wrote in some of the previous e-mails, the following from your results.csv
looks suspicious:

DL1_RELOADS,18240,100.00
IL1_FETCH_RELOADS,11714,100.00
L1_STASH_HIT,0,100.00
L1_STASH_REQ,0,100.00
L1_CACHE_MISSES,0,100.00
L1_CACHE_LOAD_MISSES,0,100.00
L1_CACHE_STORE_MISSES,0,100.00

While DL1_RELOADS and IL1_FETCH_RELOADS events give some non-zero results, the
L1_CACHE_MISSES, L1_CACHE_LOAD_MISSES and L1_CACHE_STORE_MISSES are zero. This
is probably wrong. Since the L1_CACHE_MISSES event and the LOAD/STORE brothers
are e6500-only, I guess they are a sign that e5500 cannot have the e6500 event
set. You can prove this guess by checking whether you are able to get non-zero
values here with cache-stressing or not.

Second thing I picked from your results is the CLK_FPU_DIV:

It should count cycles spent in fdivs or fdiv instructions. So I'd try to test
it by something like:

#include <stdio.h>
#include <stdlib.h>
int main(int argc, char *argv[])
{
 	double a = atof(argv[1]);
 	double b = 3.14159265;
 	double c = a / b;
 	printf("res = %lf\n", c);
 	return 0;
}

gcc -o div -O0 -g div.c

Check whether it contains the fdif or fdivs instrucions by:

objdump -d div

If it contains the instructions, try to get a nonzero result from CLK_FPU_DIV:

ocount -e CLK_FPU_DIV ./div 23445


Thanks.
Michael

RE: oprofile support for PPC_E5500

[Michael Petlan <mpetlan@re...>]

I have forgot the cache-stressing sample program.

RE: oprofile support for PPC_E5500

[Beaman, Thomas <Thomas.B<eaman@xe...>]

> -----Original Message-----
> From: Michael Petlan [mailto:mpetlan@...]
> Sent: Tuesday, July 12, 2016 4:48 PM
> To: Beaman, Thomas
> Cc: William Cohen; oprofile-list@...
> Subject: RE: oprofile support for PPC_E5500
> 
> On Tue, 12 Jul 2016, Beaman, Thomas wrote:
> >
> >>
> >> Hi Tom,
> >>
> >> Thanks for making the request to Windriver for the e6500 oprofile patch.
> >>
> >> Are there similar special patches in kernel being used to allow
> >> access to the
> >> e5500 performance monitoring hardware?  I see references to e500 and
> >> e6500 in the mainline kernel (linux/arch/power/perf/e500-pmu.c and
> >> linux/arch/power/perf/e6500-pmu.c, but don't see anything for e5500.
> >> Does "perf list" work and list out events thave "[Hardware event]" or
> >> "[Kernel PMU event]" on the line?  If the kernel support isn't there,
> >> then changes to the user-space oprofile isn't make much of a difference.
> >>
> >> -Will
> >
> >
> > Hi Will,
> >
> > So far I am only using Michaels patch plus a few hand edits I make, which
> allows detection of the cpu.
> >
> > I have attached the output of the "perf list" command.  It does have
> > some Hardware Events listed
> >
> > Tom
> >
> 
> Since the `perf list` shows stalled-cycles-frontend and stalled-cycles-backend
> events, it seems it does not use the e6500-pmu.c file, since these events are
> specified in e500-pmu.c only.
> 
> Tom, the question was whether WindRiver has some kernel patches for
> e5500 support or not.
> 
> You may also try to see which PMU drivers are present in kallsyms:
> 
> cat /proc/kallsyms | grep pmu | grep init
> 
> If you see e5500 there, your kernel probably has some WindRiver-specific
> patch, since there is probably no init_e5500_pmu in the upstream kernel.
> 
> Michael

Hi Michael,  

There are no specific WindRiver patches that I can see for the e5500 and there is no init_e5500 in kallsyms. How do you think we should proceed ?  

Thanks,
Tom

root@...:~# cat /proc/kallsyms | grep pmu | grep init
c000000000059de8 t .fsl_emb_pmu_event_init
c00000000005acf0 t .init_e500_pmu
c00000000005ade4 t .init_e6500_pmu
c000000000c51f10 t __initcall_init_e500_pmuearly
c000000000c51f18 t __initcall_init_e6500_pmuearly
c000000000d3e480 d fsl_emb_pmu_event_init
c000000000d3e5b8 d init_e500_pmu
c000000000d3e5e8 d init_e6500_pmu

RE: oprofile support for PPC_E5500

[Michael Petlan <mpetlan@re...>]

On Tue, 12 Jul 2016, Beaman, Thomas wrote:
>
>>
>> Hi Tom,
>>
>> Thanks for making the request to Windriver for the e6500 oprofile patch.
>>
>> Are there similar special patches in kernel being used to allow access to the
>> e5500 performance monitoring hardware?  I see references to e500 and
>> e6500 in the mainline kernel (linux/arch/power/perf/e500-pmu.c and
>> linux/arch/power/perf/e6500-pmu.c, but don't see anything for e5500.  Does
>> "perf list" work and list out events thave "[Hardware event]" or "[Kernel
>> PMU event]" on the line?  If the kernel support isn't there, then changes to
>> the user-space oprofile isn't make much of a difference.
>>
>> -Will
>
>
> Hi Will,
>
> So far I am only using Michaels patch plus a few hand edits I make, which allows detection of the cpu.
>
> I have attached the output of the "perf list" command.  It does have some Hardware Events listed
>
> Tom
>

Since the `perf list` shows stalled-cycles-frontend and stalled-cycles-backend
events, it seems it does not use the e6500-pmu.c file, since these events are
specified in e500-pmu.c only.

Tom, the question was whether WindRiver has some kernel patches for e5500 support
or not.

You may also try to see which PMU drivers are present in kallsyms:

cat /proc/kallsyms | grep pmu | grep init

If you see e5500 there, your kernel probably has some WindRiver-specific patch,
since there is probably no init_e5500_pmu in the upstream kernel.

Michael

RE: oprofile support for PPC_E5500

[Michael Petlan <mpetlan@re...>]

On Mon, 11 Jul 2016, Beaman, Thomas wrote:
>
>>
>> I don't see any ppc64/e6500 dir. Do you have the same git tree?
>> https://sourceforge.net/p/oprofile/oprofile/ci/master/tree/events/ppc64/
>
> I did some looking into this, and I have oprofile version 1.1.0 but my linux vendor (WindRiver linux) does add a patch called
>
> oprofile-wr-add-ppc64-e6500-support.patch
>
> which adds entries to the ppc64 event dir and updates the op_cpu_type.c file with a ppc64/e6500  entry.  (very similar type of updates as your patch)

Could this patch be posted here to review?

William, I am a bit doubtful after looking at the code, whether we even support
the e6500 at all.

1) In libop/op_cpu_type.c, the function __get_cpu_type does not have anything to
support ppc32, so I don't see a path for 32bit ppc there.

2) In case e6500 runs in ppc64 mode, it probably jumps into _get_ppc64_cpu_type,
where it constructs the path to the events file, however, it can point only into
the ppc64 dir (libop/op_cpu_type.c, line 333).

That might be why the WindRiver linux needs the additional patch. I don't have any
similar CPU to test on.

>
>
>>
>
> What you say is probably correct for intel, but from actual testing this does not appear to be the case for PowerPC.  If I do not have the ppc64/e5500 entries the cpu is NOT detected.  This is probably why Windriver has added the ppc64/e6500 patch.
>
>

That might make sense, as it's been said above. However, if the hypothesis is right,
we'd need some more fixes in order to enable the CPUs.

>>>
>
> The problem with the script is my system would not accept sleep 0.2. I have changed it to sleep 1 and now it is working.  I have attached the output files events.list, results.log and supported.list
>

Thanks, it looks fine. However, 123 out of 201 events give zero values. It does not have
to be a problem. However, some events should return something.

Could you please test ocount against some more cache-stressing command than sleep and
test L1_CACHE_MISSES, L1_CACHE_LOAD_MISSES and L1_CACHE_STORE_MISSES? Also, please try
out a simple test, whether L1_CACHE_MISSES = L1_CACHE_LOAD_MISSES + L1_CACHE_STORE_MISSES.

Also, please try out, whether you can measure anything non-zero with CLK_FPU_DIV, when
counting against a program doing floating point divisions.

The FPU events are in E6500 only, not in E500MC. The same with the L1_CACHE_* events.
However, there were some DL1_RELOADS and IL1_FETCH_RELOADS, but no L1_CACHE_* events,
so this looks suspicious. Maybe E5500 has different event set than E6500. Maybe it is
more similar to E500mc, maybe not.

It would be really helpful to have an expert insight into the event sets availale.

>>>

Thanks,
Michael

Re: oprofile support for PPC_E5500

[William Cohen <wcohen@re...>]

On 07/11/2016 02:36 PM, Beaman, Thomas wrote:
> 
>> -----Original Message-----
>> From: Michael Petlan [mailto:mpetlan@...]
>> Sent: Friday, July 08, 2016 1:16 PM
>> To: Beaman, Thomas
>> Cc: Michael Petlan; William Cohen; oprofile-list@...
>> Subject: RE: oprofile support for PPC_E5500
>>
>> On Fri, 8 Jul 2016, Beaman, Thomas wrote:
>>> Hi Michael,
>>>
>>
>> Hi Tom,
>>
>>> I wanted to update you on my status. I was able to apply your patch, but I
>> did notice a few recommendations for change.
>>>
>>> The E5500 is a 64 bit cpu like the E6500. I have noticed that the E6500 has
>> entries in both the ppc and ppc64 directories.  Also the op_cpu_type.c  file
>> has two entries  ppc/e6500 and ppc64/e6500. I believe the e5500 should also
>> be like this.
>>
>> I don't see any ppc64/e6500 dir. Do you have the same git tree?
>> https://sourceforge.net/p/oprofile/oprofile/ci/master/tree/events/ppc64/
> 
> I did some looking into this, and I have oprofile version 1.1.0 but my linux vendor (WindRiver linux) does add a patch called
> 
> oprofile-wr-add-ppc64-e6500-support.patch
> 
> which adds entries to the ppc64 event dir and updates the op_cpu_type.c file with a ppc64/e6500  entry.  (very similar type of updates as your patch) 

Hi Thomas,

Would it be possible to have someone from Wind River submit the e6500 patch for review?  It would be nice to eliminate the need for this patch for the next oprofile release.

It does look like the pmu control hardware is pretty similar for e500, e5500, and e6500: http://cache.freescale.com/files/32bit/doc/ref_manual/EREF_RM.pdf.  However, the actual performance events supported for the e500 and e6500 differ.  It is likely there are event differences between e5500 and e6500 so simply including e6500 for e5500 is likely to have some incorrect entries.  However, I haven't found a list of events for the e5500 around.


-Will
> 
>>
>> [Michael@... oprofile]$ ls events/ppc64 events/ppc
>> events/ppc:
>> 7450  e300  e500  e500mc  e500v2  e5500  e6500
>> events/ppc64:
>> 970  970MP  architected_events_v1  power4  power5  power5+  power5++
>> power6  power7  power8
>>
>> The same with op_cpu_type.c:
>>
>> [Michael@... oprofile]$ grep -P -i ppc6?4?/e6500 ./libop/op_cpu_type.c
>>          { "e6500", "ppc/e6500", CPU_PPC_E6500, 6 },
>>
>> Anyway, it should not matter whether the events/unit_masks files are in ppc
>> or ppc64 dir, as you can see, Intel datafiles are in i386 dir while AMD files are
>> in x86-64, no matter that Intel CPUs run in 64bit mode now. Regarding to the
>> ppc/ppc64, you can see that ppc64 dir contains IBM POWER processors, while
>> ppc is for the others.
>>
> 
> What you say is probably correct for intel, but from actual testing this does not appear to be the case for PowerPC.  If I do not have the ppc64/e5500 entries the cpu is NOT detected.  This is probably why Windriver has added the ppc64/e6500 patch.
>  
> 
>>>
>>> After applying your patch I made the following changes by hand.
>>>
>>> Add ppc64/e5500  event and unit_masks (with includes pointing to
>>> ppc64/e6500) Add ppc64/e5500 entry to op_cpu_type.c Fix typo in
>>> ppc/unit_masks  include:ppc/6500  should be  include:ppc/e6500
>> Yes, I haven't noticed the typo. Thanks.
>>
>>>
>>> After these changes I am now able to run ophelp and it list lots of info, so it
>> is now detecting the cpu.
>>
>> The command `ophelp -r` should print the processor type If ophelp is
>> reporting events, it is good news.
>>
> 
> root@...:~# ophelp -r
> e5500
> 
> but I can only get this if I have ppc64/e5500 entries in op_cpu_type.c and the ppc64/e5500 directory.
> 
> 
>>>
>>> I tried running your check_events.sh script but was running into problems.
>> I am off until Monday but I wanted to give you a status update. If you want
>> to modify the patch I can test a new one on Monday and also figure out what
>> is going on with check_events.
>>
>> The script just parses all the supported events from ophelp and then it runs
>> `ocount -b -e $event -- sleep 0.2` against each of them.
>>
>> There's no E5500 or any other similar CPU available for me, just an IBM
>> POWER7 box and I have no problems running the script there.
>>
>> You may try it manually:
>>
>> perl -ne 'print "$1\n" if /name:(\w+)\s/' < events/ppc/e6500/events >
>> events.list for i in `cat events.list`; do
>>  	ocount -b -e $i -- sleep 0.2 >> result.log done
>>
> 
> The problem with the script is my system would not accept sleep 0.2. I have changed it to sleep 1 and now it is working.  I have attached the output files events.list, results.log and supported.list
> 
>>>
>>> I do not know the posting protocol, should I be posting this reply to the
>> oprofile-list or is direct communications acceptable ?   If it should go to the list
>> can you forward it on and let me know for future postings.
>>
>> It's always better when the messages go to the list, since other people might
>> find them useful later on.
>>
>>>
>>> Thanks for your help so far,
>>> Tom
>>
>> Michael
>>
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Michael Petlan [mailto:mpetlan@...]
>>> Sent: Thursday, July 07, 2016 10:48 AM
>>> To: Beaman, Thomas
>>> Cc: oprofile-list@...
>>> Subject: Re: oprofile support for PPC_E5500
>>>
>>> Hi,
>>>
>>> could you please test the attached patch?
>>>
>>> E6500 also has the same PMU events as E500mc plus some more.
>>> It would be good to know what the set of events supported by the E5500
>> actually is.
>>>
>>> Please run the oprofile-tests testsuite and the attached test and send the
>> logs from the second one?
>>>
>>> Anyway, it would be nice if someone more appropriate reviewed the
>> events and checks the kernel support, etc.
>>>
>>> Thanks.
>>> Michael
>>>
>>>
>>> On Wed, 6 Jul 2016, Beaman, Thomas wrote:
>>>> When I am running on my PPC E5500 system oprofile cannot detect the
>>>> CPU
>>>>
>>>>
>>>>
>>>> operf --version
>>>>
>>>> Unable to obtain cpu_type
>>>>
>>>>
>>>>
>>>> Looking at op_cpu_type.h I see entries for
>>>>
>>>>
>>>>
>>>>                 CPU_PPC_E500MC, /**< e500mc */
>>>>
>>>>                 CPU_PPC_E6500, /**< e6500 */
>>>>
>>>>
>>>>
>>>> But no entry for the PPC E5500.  The E5500 is very similar to e500mc and
>> the E6500.  Can support be added for this processor ?
>>>>
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Tom
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>

RE: oprofile support for PPC_E5500

[Beaman, Thomas <Thomas.B<eaman@xe...>]

> -----Original Message-----
> From: Michael Petlan [mailto:mpetlan@...]
> Sent: Friday, July 08, 2016 1:16 PM
> To: Beaman, Thomas
> Cc: Michael Petlan; William Cohen; oprofile-list@...
> Subject: RE: oprofile support for PPC_E5500
> 
> On Fri, 8 Jul 2016, Beaman, Thomas wrote:
> > Hi Michael,
> >
> 
> Hi Tom,
> 
> > I wanted to update you on my status. I was able to apply your patch, but I
> did notice a few recommendations for change.
> >
> > The E5500 is a 64 bit cpu like the E6500. I have noticed that the E6500 has
> entries in both the ppc and ppc64 directories.  Also the op_cpu_type.c  file
> has two entries  ppc/e6500 and ppc64/e6500. I believe the e5500 should also
> be like this.
> 
> I don't see any ppc64/e6500 dir. Do you have the same git tree?
> https://sourceforge.net/p/oprofile/oprofile/ci/master/tree/events/ppc64/

I did some looking into this, and I have oprofile version 1.1.0 but my linux vendor (WindRiver linux) does add a patch called

oprofile-wr-add-ppc64-e6500-support.patch

which adds entries to the ppc64 event dir and updates the op_cpu_type.c file with a ppc64/e6500  entry.  (very similar type of updates as your patch) 


> 
> [Michael@... oprofile]$ ls events/ppc64 events/ppc
> events/ppc:
> 7450  e300  e500  e500mc  e500v2  e5500  e6500
> events/ppc64:
> 970  970MP  architected_events_v1  power4  power5  power5+  power5++
> power6  power7  power8
> 
> The same with op_cpu_type.c:
> 
> [Michael@... oprofile]$ grep -P -i ppc6?4?/e6500 ./libop/op_cpu_type.c
>          { "e6500", "ppc/e6500", CPU_PPC_E6500, 6 },
> 
> Anyway, it should not matter whether the events/unit_masks files are in ppc
> or ppc64 dir, as you can see, Intel datafiles are in i386 dir while AMD files are
> in x86-64, no matter that Intel CPUs run in 64bit mode now. Regarding to the
> ppc/ppc64, you can see that ppc64 dir contains IBM POWER processors, while
> ppc is for the others.
> 

What you say is probably correct for intel, but from actual testing this does not appear to be the case for PowerPC.  If I do not have the ppc64/e5500 entries the cpu is NOT detected.  This is probably why Windriver has added the ppc64/e6500 patch.
 

> >
> > After applying your patch I made the following changes by hand.
> >
> > Add ppc64/e5500  event and unit_masks (with includes pointing to
> > ppc64/e6500) Add ppc64/e5500 entry to op_cpu_type.c Fix typo in
> > ppc/unit_masks  include:ppc/6500  should be  include:ppc/e6500
> Yes, I haven't noticed the typo. Thanks.
> 
> >
> > After these changes I am now able to run ophelp and it list lots of info, so it
> is now detecting the cpu.
> 
> The command `ophelp -r` should print the processor type If ophelp is
> reporting events, it is good news.
> 

root@...:~# ophelp -r
e5500

but I can only get this if I have ppc64/e5500 entries in op_cpu_type.c and the ppc64/e5500 directory.


> >
> > I tried running your check_events.sh script but was running into problems.
> I am off until Monday but I wanted to give you a status update. If you want
> to modify the patch I can test a new one on Monday and also figure out what
> is going on with check_events.
> 
> The script just parses all the supported events from ophelp and then it runs
> `ocount -b -e $event -- sleep 0.2` against each of them.
> 
> There's no E5500 or any other similar CPU available for me, just an IBM
> POWER7 box and I have no problems running the script there.
> 
> You may try it manually:
> 
> perl -ne 'print "$1\n" if /name:(\w+)\s/' < events/ppc/e6500/events >
> events.list for i in `cat events.list`; do
>  	ocount -b -e $i -- sleep 0.2 >> result.log done
> 

The problem with the script is my system would not accept sleep 0.2. I have changed it to sleep 1 and now it is working.  I have attached the output files events.list, results.log and supported.list

> >
> > I do not know the posting protocol, should I be posting this reply to the
> oprofile-list or is direct communications acceptable ?   If it should go to the list
> can you forward it on and let me know for future postings.
> 
> It's always better when the messages go to the list, since other people might
> find them useful later on.
> 
> >
> > Thanks for your help so far,
> > Tom
> 
> Michael
> 
> >
> >
> >
> >
> > -----Original Message-----
> > From: Michael Petlan [mailto:mpetlan@...]
> > Sent: Thursday, July 07, 2016 10:48 AM
> > To: Beaman, Thomas
> > Cc: oprofile-list@...
> > Subject: Re: oprofile support for PPC_E5500
> >
> > Hi,
> >
> > could you please test the attached patch?
> >
> > E6500 also has the same PMU events as E500mc plus some more.
> > It would be good to know what the set of events supported by the E5500
> actually is.
> >
> > Please run the oprofile-tests testsuite and the attached test and send the
> logs from the second one?
> >
> > Anyway, it would be nice if someone more appropriate reviewed the
> events and checks the kernel support, etc.
> >
> > Thanks.
> > Michael
> >
> >
> > On Wed, 6 Jul 2016, Beaman, Thomas wrote:
> >> When I am running on my PPC E5500 system oprofile cannot detect the
> >> CPU
> >>
> >>
> >>
> >> operf --version
> >>
> >> Unable to obtain cpu_type
> >>
> >>
> >>
> >> Looking at op_cpu_type.h I see entries for
> >>
> >>
> >>
> >>                 CPU_PPC_E500MC, /**< e500mc */
> >>
> >>                 CPU_PPC_E6500, /**< e6500 */
> >>
> >>
> >>
> >> But no entry for the PPC E5500.  The E5500 is very similar to e500mc and
> the E6500.  Can support be added for this processor ?
> >>
> >>
> >>
> >> Thanks,
> >>
> >> Tom
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >

Re: [patch 53/66] MIPS: Loongson-3: Convert oprofile to hotplug state machine

[Ralf Baechle <ralf@li...>]

Thank, looks ok.  I assume you want to merge this with the remainder of
of the series, so:

Acked-by: Ralf Baechle <ralf@...>

  Ralf

[patch 53/66] MIPS: Loongson-3: Convert oprofile to hotplug state machine

[Anna-Maria Gleixner <anna-maria@li...>]

From: Richard Cochran <rcochran@...>

Install the callbacks via the state machine and let the core invoke
the callbacks on the already online CPUs.

Signed-off-by: Richard Cochran <rcochran@...>
Reviewed-by: Sebastian Andrzej Siewior <bigeasy@...>
Cc: Robert Richter <rric@...>
Cc: Ralf Baechle <ralf@...>
Cc: oprofile-list@...
Cc: linux-mips@...
Signed-off-by: Anna-Maria Gleixner <anna-maria@...>

---
 arch/mips/oprofile/op_model_loongson3.c |   35 ++++++++++++--------------------
 include/linux/cpuhotplug.h              |    1 
 2 files changed, 15 insertions(+), 21 deletions(-)

--- a/arch/mips/oprofile/op_model_loongson3.c
+++ b/arch/mips/oprofile/op_model_loongson3.c
@@ -168,33 +168,26 @@ static int loongson3_perfcount_handler(v
 	return handled;
 }
 
-static int loongson3_cpu_callback(struct notifier_block *nfb,
-	unsigned long action, void *hcpu)
+static int loongson3_starting_cpu(unsigned int cpu)
 {
-	switch (action) {
-	case CPU_STARTING:
-	case CPU_STARTING_FROZEN:
-		write_c0_perflo1(reg.control1);
-		write_c0_perflo2(reg.control2);
-		break;
-	case CPU_DYING:
-	case CPU_DYING_FROZEN:
-		write_c0_perflo1(0xc0000000);
-		write_c0_perflo2(0x40000000);
-		break;
-	}
-
-	return NOTIFY_OK;
+	write_c0_perflo1(reg.control1);
+	write_c0_perflo2(reg.control2);
+	return 0;
 }
 
-static struct notifier_block loongson3_notifier_block = {
-	.notifier_call = loongson3_cpu_callback
-};
+static int loongson3_dying_cpu(unsigned int cpu)
+{
+	write_c0_perflo1(0xc0000000);
+	write_c0_perflo2(0x40000000);
+	return 0;
+}
 
 static int __init loongson3_init(void)
 {
 	on_each_cpu(reset_counters, NULL, 1);
-	register_hotcpu_notifier(&loongson3_notifier_block);
+	cpuhp_setup_state_nocalls(CPUHP_AP_MIPS_OP_LOONGSON3_STARTING,
+				  "AP_MIPS_OP_LOONGSON3_STARTING",
+				  loongson3_starting_cpu, loongson3_dying_cpu);
 	save_perf_irq = perf_irq;
 	perf_irq = loongson3_perfcount_handler;
 
@@ -204,7 +197,7 @@ static int __init loongson3_init(void)
 static void loongson3_exit(void)
 {
 	on_each_cpu(reset_counters, NULL, 1);
-	unregister_hotcpu_notifier(&loongson3_notifier_block);
+	cpuhp_remove_state_nocalls(CPUHP_AP_MIPS_OP_LOONGSON3_STARTING);
 	perf_irq = save_perf_irq;
 }
 
--- a/include/linux/cpuhotplug.h
+++ b/include/linux/cpuhotplug.h
@@ -36,6 +36,7 @@ enum cpuhp_state {
 	CPUHP_AP_PERF_X86_CSTATE_STARTING,
 	CPUHP_AP_PERF_XTENSA_STARTING,
 	CPUHP_AP_PERF_METAG_STARTING,
+	CPUHP_AP_MIPS_OP_LOONGSON3_STARTING,
 	CPUHP_AP_ARM_VFP_STARTING,
 	CPUHP_AP_PERF_ARM_STARTING,
 	CPUHP_AP_ARM_L2X0_STARTING,

RE: oprofile support for PPC_E5500

[Michael Petlan <mpetlan@re...>]

On Fri, 8 Jul 2016, Beaman, Thomas wrote:
> Hi Michael,
>

Hi Tom,

> I wanted to update you on my status. I was able to apply your patch, but I did notice a few recommendations for change.
>
> The E5500 is a 64 bit cpu like the E6500. I have noticed that the E6500 has entries in both the ppc and ppc64 directories.  Also the op_cpu_type.c  file has two entries  ppc/e6500 and ppc64/e6500. I believe the e5500 should also be like this.

I don't see any ppc64/e6500 dir. Do you have the same git tree?

https://sourceforge.net/p/oprofile/oprofile/ci/master/tree/events/ppc64/

[Michael@... oprofile]$ ls events/ppc64 events/ppc
events/ppc:
7450  e300  e500  e500mc  e500v2  e5500  e6500
events/ppc64:
970  970MP  architected_events_v1  power4  power5  power5+  power5++  power6  power7  power8

The same with op_cpu_type.c:

[Michael@... oprofile]$ grep -P -i ppc6?4?/e6500 ./libop/op_cpu_type.c
         { "e6500", "ppc/e6500", CPU_PPC_E6500, 6 },

Anyway, it should not matter whether the events/unit_masks files are in ppc or ppc64 dir,
as you can see, Intel datafiles are in i386 dir while AMD files are in x86-64, no matter
that Intel CPUs run in 64bit mode now. Regarding to the ppc/ppc64, you can see that ppc64
dir contains IBM POWER processors, while ppc is for the others.

>
> After applying your patch I made the following changes by hand.
>
> Add ppc64/e5500  event and unit_masks (with includes pointing to ppc64/e6500)
> Add ppc64/e5500 entry to op_cpu_type.c
> Fix typo in ppc/unit_masks  include:ppc/6500  should be  include:ppc/e6500
Yes, I haven't noticed the typo. Thanks.

>
> After these changes I am now able to run ophelp and it list lots of info, so it is now detecting the cpu.

The command `ophelp -r` should print the processor type
If ophelp is reporting events, it is good news.

>
> I tried running your check_events.sh script but was running into problems.  I am off until Monday but I wanted to give you a status update. If you want to modify the patch I can test a new one on Monday and also figure out what is going on with check_events.

The script just parses all the supported events from ophelp and then it runs
`ocount -b -e $event -- sleep 0.2` against each of them.

There's no E5500 or any other similar CPU available for me, just an IBM POWER7
box and I have no problems running the script there.

You may try it manually:

perl -ne 'print "$1\n" if /name:(\w+)\s/' < events/ppc/e6500/events > events.list
for i in `cat events.list`; do
 	ocount -b -e $i -- sleep 0.2 >> result.log
done

>
> I do not know the posting protocol, should I be posting this reply to the oprofile-list or is direct communications acceptable ?   If it should go to the list can you forward it on and let me know for future postings.

It's always better when the messages go to the list, since other people might find
them useful later on.

>
> Thanks for your help so far,
> Tom

Michael

>
>
>
>
> -----Original Message-----
> From: Michael Petlan [mailto:mpetlan@...]
> Sent: Thursday, July 07, 2016 10:48 AM
> To: Beaman, Thomas
> Cc: oprofile-list@...
> Subject: Re: oprofile support for PPC_E5500
>
> Hi,
>
> could you please test the attached patch?
>
> E6500 also has the same PMU events as E500mc plus some more.
> It would be good to know what the set of events supported by the E5500 actually is.
>
> Please run the oprofile-tests testsuite and the attached test and send the logs from the second one?
>
> Anyway, it would be nice if someone more appropriate reviewed the events and checks the kernel support, etc.
>
> Thanks.
> Michael
>
>
> On Wed, 6 Jul 2016, Beaman, Thomas wrote:
>> When I am running on my PPC E5500 system oprofile cannot detect the
>> CPU
>>
>>  
>>
>> operf --version
>>
>> Unable to obtain cpu_type
>>
>>  
>>
>> Looking at op_cpu_type.h I see entries for
>>
>>  
>>
>>                 CPU_PPC_E500MC, /**< e500mc */
>>
>>                 CPU_PPC_E6500, /**< e6500 */
>>
>>  
>>
>> But no entry for the PPC E5500.  The E5500 is very similar to e500mc and the E6500.  Can support be added for this processor ?
>>
>>  
>>
>> Thanks,
>>
>> Tom
>>
>>  
>>
>>  
>>
>>
>>
>

RE: oprofile support for PPC_E5500

[Beaman, Thomas <Thomas.B<eaman@xe...>]

-----Original Message-----
From: William Cohen [mailto:wcohen@...] 
Sent: Thursday, July 07, 2016 10:33 AM
To: Beaman, Thomas; oprofile-list@...
Subject: Re: oprofile support for PPC_E5500

On 07/06/2016 10:26 AM, Beaman, Thomas wrote:
> When I am running on my PPC E5500 system oprofile cannot detect the CPU
> 
>  
> 
> operf --version
> 
> Unable to obtain cpu_type
> 
>  
> 
> Looking at op_cpu_type.h I see entries for
> 
>  
> 
>                 CPU_PPC_E500MC, /**< e500mc */
> 
>                 CPU_PPC_E6500, /**< e6500 */
> 
>  
> 
> But no entry for the PPC E5500.  The E5500 is very similar to e500mc and the E6500.  Can support be added for this processor ?
> 
>  
> 
> Thanks,
> 
> Tom

Hi Tom,

It is not difficult to add support for additional processors to oprofile. The main question is does the kernel being used on the system support access to the PPC E5500 performance monitoring hardware.  OProfile now uses the linux perf infrastructure in the kernel.  If that is available on the machine the command "perf list" should list out the available events and include some that are hardware events.  For the older method that is no longer supported in the current version of oprofile the kernel provided a oprofile kernel module.  The kernel module provided information about what type of processor the machine was. 

To add support for a new process there will need to be some additions in oprofile libop files to identify the processor type.  descriptions of the events in events/ppc for the processor.  The events might be similar to other existing processors and you might be able to map the processor to an existing set of events, but there can be differences that require separate set of files describing the events.

-Will

>>>>>>>>>>>>>>>>>


Hi Will,

The kernel I have does support a current version of OProfile. I have OProfile 1.1.0 running on a 4.1 kernel on a different CPU (X86_64).  I have checked and perf does list the following hardware events for the ppc E5500 target. 

  branch-instructions OR branches                    [Hardware event]
  branch-misses                                      [Hardware event]
  cache-misses                                       [Hardware event]
  cpu-cycles OR cycles                               [Hardware event]
  instructions                                       [Hardware event]
  stalled-cycles-backend OR idle-cycles-backend      [Hardware event]
  stalled-cycles-frontend OR idle-cycles-frontend    [Hardware event]

Michael Petlan has also replied with a patch for the ppc-e5500 that I will try. Thanks for your quick reply,  let me know if there is any other info I can supply.

Tom

Re: oprofile support for PPC_E5500

[Michael Petlan <mpetlan@re...>]

Hi,

could you please test the attached patch?

E6500 also has the same PMU events as E500mc plus some more.
It would be good to know what the set of events supported by
the E5500 actually is.

Please run the oprofile-tests testsuite and the attached test
and send the logs from the second one?

Anyway, it would be nice if someone more appropriate reviewed
the events and checks the kernel support, etc.

Thanks.
Michael


On Wed, 6 Jul 2016, Beaman, Thomas wrote:
> When I am running on my PPC E5500 system oprofile cannot detect the CPU
> 
>  
> 
> operf --version
> 
> Unable to obtain cpu_type
> 
>  
> 
> Looking at op_cpu_type.h I see entries for
> 
>  
> 
>                 CPU_PPC_E500MC, /**< e500mc */
> 
>                 CPU_PPC_E6500, /**< e6500 */
> 
>  
> 
> But no entry for the PPC E5500.  The E5500 is very similar to e500mc and the E6500.  Can support be added for this processor ?
> 
>  
> 
> Thanks,
> 
> Tom
> 
>  
> 
>  
> 
> 
>

Re: oprofile support for PPC_E5500

[William Cohen <wcohen@re...>]

On 07/06/2016 10:26 AM, Beaman, Thomas wrote:
> When I am running on my PPC E5500 system oprofile cannot detect the CPU
> 
>  
> 
> operf --version
> 
> Unable to obtain cpu_type
> 
>  
> 
> Looking at op_cpu_type.h I see entries for
> 
>  
> 
>                 CPU_PPC_E500MC, /**< e500mc */
> 
>                 CPU_PPC_E6500, /**< e6500 */
> 
>  
> 
> But no entry for the PPC E5500.  The E5500 is very similar to e500mc and the E6500.  Can support be added for this processor ?
> 
>  
> 
> Thanks,
> 
> Tom

Hi Tom,

It is not difficult to add support for additional processors to oprofile. The main question is does the kernel being used on the system support access to the PPC E5500 performance monitoring hardware.  OProfile now uses the linux perf infrastructure in the kernel.  If that is available on the machine the command "perf list" should list out the available events and include some that are hardware events.  For the older method that is no longer supported in the current version of oprofile the kernel provided a oprofile kernel module.  The kernel module provided information about what type of processor the machine was. 

To add support for a new process there will need to be some additions in oprofile libop files to identify the processor type.  descriptions of the events in events/ppc for the processor.  The events might be similar to other existing processors and you might be able to map the processor to an existing set of events, but there can be differences that require separate set of files describing the events.

-Will

[PATCH] Store samples in the archive and search the appropriate places for samples

[William Cohen <wcohen@re...>]

Newer versions of oprofile use a oprofile_data directory in the
current working directory to store the samples.  This presents a
complications when data archived with oparchive.  The oparchive needs
to include samples in the archive.  The code also needs to make sure
that samples in the archive are used and not samples from a
oprofile_data directory in the current working directory.

Signed-off-by: William Cohen <wcohen@...>
---
 libpp/profile_spec.cpp   |  2 ++
 pp/oparchive.cpp         | 39 ++++++++++++++++++++++++++++-----------
 pp/oparchive_options.cpp |  5 ++---
 3 files changed, 32 insertions(+), 14 deletions(-)

diff --git a/libpp/profile_spec.cpp b/libpp/profile_spec.cpp
index cd4bd80..a10d6cc 100644
--- a/libpp/profile_spec.cpp
+++ b/libpp/profile_spec.cpp
@@ -102,6 +102,8 @@ void profile_spec::set_image_or_lib_name(string const & str)
 void profile_spec::parse_archive_path(string const & str)
 {
 	archive_path = op_realpath(str);
+	/* Need to force session directory default location in the archive */
+	init_op_config_dirs(OP_SESSION_DIR_DEFAULT);
 }
 
 
diff --git a/pp/oparchive.cpp b/pp/oparchive.cpp
index 5b6906d..6221e14 100644
--- a/pp/oparchive.cpp
+++ b/pp/oparchive.cpp
@@ -232,6 +232,19 @@ int oparchive(options::spec const & spec)
 		}
 	}
 
+	/* place samples and other related material in easily found default directory */
+	string dest_session_dir = options::outdirectory + string(OP_SESSION_DIR_DEFAULT);
+	string dest_samples_dir = dest_session_dir + string("samples");
+
+	/* dest_session_dir is parent of dest_samples and will also created */
+
+	if (!options::list_files &&
+	    create_path(dest_samples_dir.c_str())) {
+		cerr << "Unable to create directory for "
+		     <<	dest_samples_dir << "." << endl;
+		exit (EXIT_FAILURE);
+	}
+
 	/* copy over each of the sample files */
 	list<string>::iterator sit = sample_files.begin();
 	list<string>::iterator const send = sample_files.end();
@@ -245,9 +258,13 @@ int oparchive(options::spec const & spec)
 
 	for (; sit != send; ++sit) {
 		string sample_name = *sit;
+		/* determine the session name of sample file */
+		int offset = sample_name.find('{');
+		string base_samples_dir = sample_name.substr(0, offset-1);
+		string session = basename(base_samples_dir.c_str());
 		/* Get rid of the the archive_path from the name */
-		string sample_base = sample_name.substr(archive_path.size());
-		string sample_archive_file = options::outdirectory + sample_base;
+		string sample_base = sample_name.substr(offset);
+		string sample_archive_file = dest_samples_dir + "/" + session + "/" + sample_base;
 		
 		cverb << vdebug << sample_name << endl;
 		cverb << vdebug << " destp " << sample_archive_file << endl;
@@ -268,19 +285,19 @@ int oparchive(options::spec const & spec)
 		cerr << "Unable to to obtain realpath for " << op_session_dir << endl;
 		exit (EXIT_FAILURE);
 	}
-	string abi_name = string(real_session_dir) + "/abi";
-	copy_one_file(image_ok, archive_path + abi_name,
-	              options::outdirectory + abi_name);
+	string abi_name = string(real_session_dir) + string("/abi");
+	string dest_abi_name = dest_session_dir + string("/abi");
+	copy_one_file(image_ok, archive_path + abi_name, dest_abi_name);
 
 	/* copy over the <session-dir>/samples/oprofiled.log file */
-	string log_name = string(real_session_dir) + string("/samples") + "/oprofiled.log";
-	copy_one_file(image_ok, archive_path + log_name,
-	              options::outdirectory + log_name);
+	string log_name = string(real_session_dir) + string("/samples") + string("/oprofiled.log");
+	string dest_log_name = dest_samples_dir + string("/oprofiled.log");
+	copy_one_file(image_ok, archive_path + log_name, dest_log_name);
 
 	/* copy over the <session-dir>/samples/operf.log file */
-	log_name = string(real_session_dir) + string("/samples") + "/operf.log";
-	copy_one_file(image_ok, archive_path + log_name,
-	              options::outdirectory + log_name);
+	log_name = string(real_session_dir) + string("/samples") + string("/operf.log");
+	dest_log_name = dest_samples_dir + string("/operf.log");
+	copy_one_file(image_ok, archive_path + log_name, dest_log_name);
 
 	free(real_session_dir);
 
diff --git a/pp/oparchive_options.cpp b/pp/oparchive_options.cpp
index e6f2ddc..b79bf13 100644
--- a/pp/oparchive_options.cpp
+++ b/pp/oparchive_options.cpp
@@ -124,7 +124,6 @@ void handle_options(options::spec const & spec)
 
 	if (strncmp(op_session_dir, OP_SESSION_DIR_DEFAULT, strlen(OP_SESSION_DIR_DEFAULT)))
 		cerr << "NOTE: The sample data in this archive is located at " << op_session_dir << endl
-		     << "instead of the standard location of " << OP_SESSION_DIR_DEFAULT << ".  Hence, when using opreport" << endl
-		     << "and other post-processing tools on this archive, you must pass the following option:" << endl
-		     << "\t--session-dir=" << op_session_dir << endl;
+		     << "and is being moved to the standard location of " << OP_SESSION_DIR_DEFAULT << "."
+		     << endl;
 }
-- 
2.5.5