arch/powerpc/oprofile/common.c has this init code:
int __init oprofile_arch_init(struct oprofile_operations *ops)
{
if (!cur_cpu_spec->oprofile_cpu_type)
return -ENODEV;
if (firmware_has_feature(FW_FEATURE_ISERIES))
return -ENODEV;
switch (cur_cpu_spec->oprofile_type) {
#ifdef CONFIG_PPC_BOOK3S_64
#ifdef CONFIG_OPROFILE_CELL
case PPC_OPROFILE_CELL:
if (firmware_has_feature(FW_FEATURE_LPAR))
return -ENODEV;
model = &op_model_cell;
ops->sync_start = model->sync_start;
ops->sync_stop = model->sync_stop;
break;
#endif
case PPC_OPROFILE_RS64:
model = &op_model_rs64;
break;
case PPC_OPROFILE_POWER4:
model = &op_model_power4;
break;
case PPC_OPROFILE_PA6T:
model = &op_model_pa6t;
break;
#endif
#ifdef CONFIG_6xx
case PPC_OPROFILE_G4:
model = &op_model_7450;
break;
#endif
#if defined(CONFIG_FSL_EMB_PERFMON)
case PPC_OPROFILE_FSL_EMB:
model = &op_model_fsl_emb;
break;
#endif
default:
return -ENODEV;
}
model->num_counters = cur_cpu_spec->num_pmcs;
ops->cpu_type = cur_cpu_spec->oprofile_cpu_type;
ops->create_files = op_powerpc_create_files;
ops->setup = op_powerpc_setup;
ops->shutdown = op_powerpc_shutdown;
ops->start = op_powerpc_start;
ops->stop = op_powerpc_stop;
ops->backtrace = op_powerpc_backtrace;
}
Notice the first
if (!cur_cpu_spec->oprofile_cpu_type)
return -ENODEV;
if (firmware_has_feature(FW_FEATURE_ISERIES))
return -ENODEV;
For my e300c2 cpu both if's are false and I don't get support for callgraph/backtrace
support. Moving the ops->backtrace = op_powerpc_backtrace; to the top
enables backtrace for me.
This function needs fixing so its not all or nothing but I cannot make out
what is what so please, could someone look at this?
I am somewhat behind mainline so I will just use my hack for now.
Jocke
From: Maynard Johnson <hidden> Date: 2011-11-17 17:35:23
On 11/17/2011 2:38 AM, Joakim Tjernlund wrote:
arch/powerpc/oprofile/common.c has this init code:
int __init oprofile_arch_init(struct oprofile_operations *ops)
{
if (!cur_cpu_spec->oprofile_cpu_type)
return -ENODEV;
if (firmware_has_feature(FW_FEATURE_ISERIES))
return -ENODEV;
switch (cur_cpu_spec->oprofile_type) {
#ifdef CONFIG_PPC_BOOK3S_64
#ifdef CONFIG_OPROFILE_CELL
case PPC_OPROFILE_CELL:
if (firmware_has_feature(FW_FEATURE_LPAR))
return -ENODEV;
model =&op_model_cell;
ops->sync_start = model->sync_start;
ops->sync_stop = model->sync_stop;
break;
#endif
case PPC_OPROFILE_RS64:
model =&op_model_rs64;
break;
case PPC_OPROFILE_POWER4:
model =&op_model_power4;
break;
case PPC_OPROFILE_PA6T:
model =&op_model_pa6t;
break;
#endif
#ifdef CONFIG_6xx
case PPC_OPROFILE_G4:
model =&op_model_7450;
break;
#endif
#if defined(CONFIG_FSL_EMB_PERFMON)
case PPC_OPROFILE_FSL_EMB:
model =&op_model_fsl_emb;
break;
#endif
default:
return -ENODEV;
}
model->num_counters = cur_cpu_spec->num_pmcs;
ops->cpu_type = cur_cpu_spec->oprofile_cpu_type;
ops->create_files = op_powerpc_create_files;
ops->setup = op_powerpc_setup;
ops->shutdown = op_powerpc_shutdown;
ops->start = op_powerpc_start;
ops->stop = op_powerpc_stop;
ops->backtrace = op_powerpc_backtrace;
}
Notice the first
if (!cur_cpu_spec->oprofile_cpu_type)
return -ENODEV;
if (firmware_has_feature(FW_FEATURE_ISERIES))
return -ENODEV;
For my e300c2 cpu both if's are false and I don't get support for callgraph/backtrace
support. Moving the ops->backtrace = op_powerpc_backtrace; to the top
enables backtrace for me.
What kernel version are you using? Actually, looking at a 3.0.3 tree I happen
to have available, I see oprofile h/w event support (in
arch/powerpc/kernel/cputable.c) for e300c3 and e300c4, but not the other e300
flavors. I've added Andy Flemming from Freescale to cc. Maybe he knows why
e300c2 isn't supported.
-Maynard
This function needs fixing so its not all or nothing but I cannot make out
what is what so please, could someone look at this?
I am somewhat behind mainline so I will just use my hack for now.
Jocke
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
oprofile-list mailing list
oprofile-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oprofile-list
From: Andy Fleming <hidden> Date: 2011-11-17 17:52:06
On Nov 17, 2011, at 11:30 AM, Maynard Johnson wrote:
quoted
=20
Notice the first
if (!cur_cpu_spec->oprofile_cpu_type)
return -ENODEV;
=20
if (firmware_has_feature(FW_FEATURE_ISERIES))
return -ENODEV;
For my e300c2 cpu both if's are false and I don't get support for =
callgraph/backtrace
quoted
support. Moving the ops->backtrace =3D op_powerpc_backtrace; to the =
top
quoted
enables backtrace for me.
What kernel version are you using? Actually, looking at a 3.0.3 tree =
I happen to have available, I see oprofile h/w event support (in =
arch/powerpc/kernel/cputable.c) for e300c3 and e300c4, but not the other =
e300 flavors. I've added Andy Flemming from Freescale to cc. Maybe he =
knows why e300c2 isn't supported.
e300c2 does not have hardware performance monitor events.
However, it should be able to support timer-based profiling, right? And =
why not support backtrace from there? Do we require hardware counters to =
get a backtrace?
Andy
Andy Fleming [off-list ref] wrote on 2011/11/17 18:51:52:
On Nov 17, 2011, at 11:30 AM, Maynard Johnson wrote:
quoted
quoted
Notice the first
if (!cur_cpu_spec->oprofile_cpu_type)
return -ENODEV;
if (firmware_has_feature(FW_FEATURE_ISERIES))
return -ENODEV;
For my e300c2 cpu both if's are false and I don't get support for callgraph/backtrace
support. Moving the ops->backtrace = op_powerpc_backtrace; to the top
enables backtrace for me.
What kernel version are you using? Actually, looking at a 3.0.3 tree I happen to have available, I see oprofile h/w event support (in arch/powerpc/kernel/cputable.c) for e300c3 and e300c4, but not the other e300 flavors. I've added Andy Flemming from Freescale to cc. Maybe he knows why e300c2
isn't supported.
e300c2 does not have hardware performance monitor events.
However, it should be able to support timer-based profiling, right? And why not support backtrace from there? Do we require hardware counters to get a backtrace?
It sure seems to work :)
If it doesn't, one needs to make sure /dev/oprofile/backtrace_depth isn't published as it is now.
Question, what is the sample rate for timer based oprofile?
Is it HZ depended?
Jocke
From: Robert Richter <hidden> Date: 2011-11-17 23:20:36
On 17.11.11 22:27:46, Joakim Tjernlund wrote:
quoted
quoted
quoted
For my e300c2 cpu both if's are false and I don't get support for callgraph/backtrace
support. Moving the ops->backtrace = op_powerpc_backtrace; to the top
enables backtrace for me.
It sure seems to work :)
Backtrace support also works in timer mode. This is already
implemented on arm and sh (out of my mind, have to look at the code to
be sure). This works if the architectural initialization code sets up
ops->backtrace even on failure, which is exactly what you proposed.
Question, what is the sample rate for timer based oprofile?
Is it HZ depended?
Yes, it uses the high resolution timer and sets it to HZ which is 4ms
on most architectures. (I did some measurements and for some reason I
got 8ms on x86 though it should be 4ms, but didn't debug this yet.)
Unless there are volunteers I will queue up a patch for v3.3 to enable
backtrace support in timer mode.
-Robert
--
Advanced Micro Devices, Inc.
Operating System Research Center
Robert Richter [off-list ref] wrote on 2011/11/18 00:20:27:
On 17.11.11 22:27:46, Joakim Tjernlund wrote:
quoted
quoted
quoted
quoted
For my e300c2 cpu both if's are false and I don't get support for callgraph/backtrace
support. Moving the ops->backtrace = op_powerpc_backtrace; to the top
enables backtrace for me.
quoted
It sure seems to work :)
Backtrace support also works in timer mode. This is already
implemented on arm and sh (out of my mind, have to look at the code to
be sure). This works if the architectural initialization code sets up
ops->backtrace even on failure, which is exactly what you proposed.
quoted
Question, what is the sample rate for timer based oprofile?
Is it HZ depended?
Yes, it uses the high resolution timer and sets it to HZ which is 4ms
on most architectures. (I did some measurements and for some reason I
got 8ms on x86 though it should be 4ms, but didn't debug this yet.)
1-4 ms is a bit rough sample rate I guess. Ever considered using an extra
HW timer(for CPUs that has one to spare) which can set to something better?
Unless there are volunteers I will queue up a patch for v3.3 to enable
backtrace support in timer mode.
Robert Richter [off-list ref] wrote on 2011/11/18 00:20:27:
On 17.11.11 22:27:46, Joakim Tjernlund wrote:
quoted
quoted
quoted
quoted
For my e300c2 cpu both if's are false and I don't get support for callgraph/backtrace
support. Moving the ops->backtrace = op_powerpc_backtrace; to the top
enables backtrace for me.
quoted
It sure seems to work :)
Backtrace support also works in timer mode. This is already
implemented on arm and sh (out of my mind, have to look at the code to
be sure). This works if the architectural initialization code sets up
ops->backtrace even on failure, which is exactly what you proposed.
quoted
Question, what is the sample rate for timer based oprofile?
Is it HZ depended?
Yes, it uses the high resolution timer and sets it to HZ which is 4ms
on most architectures. (I did some measurements and for some reason I
got 8ms on x86 though it should be 4ms, but didn't debug this yet.)
Unless there are volunteers I will queue up a patch for v3.3 to enable
backtrace support in timer mode.
I forgot to ask, oprofile mentions setting -no-omit-framepointer to get
correct backtrace but I cannot turn on frame pointers for the ppc kernel.
Isn't frame pointers needed for pcc? what about user space?
Jocke
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2011-11-25 05:24:56
On Fri, 2011-11-18 at 09:22 +0100, Joakim Tjernlund wrote:
I forgot to ask, oprofile mentions setting -no-omit-framepointer to get
correct backtrace but I cannot turn on frame pointers for the ppc kernel.
Isn't frame pointers needed for pcc? what about user space?
PowerPC always has frame pointers, ignore that :-)
Cheers,
Ben.
On 11/25/2011 01:24 PM, Benjamin Herrenschmidt wrote:
On Fri, 2011-11-18 at 09:22 +0100, Joakim Tjernlund wrote:
quoted
I forgot to ask, oprofile mentions setting -no-omit-framepointer to get
correct backtrace but I cannot turn on frame pointers for the ppc kernel.
Isn't frame pointers needed for pcc? what about user space?
PowerPC always has frame pointers, ignore that :-)
Recently I have met a similar problem on frame pointer but at arm_v7
variant in back tracing
support for Oprofile, could you help me see it? thanks in advance:
in my case, I have enabled Oprofile support in my arm_v7 thumb2 target,
in the created binary image
including kernel image and rootfs, seems that frame pointer is not
enabled for arm thumb2, So I have met
the following problems in back trace:
I can get the right stack traces for kernel stack, but for user stack, the
stack length is always one depth, why?
Is this a known deficiency in supporting arm thumb2 for Oprofile stack
trace?
Thanks.
B.R.
--David
Cheers,
Ben.
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
oprofile-list mailing list
oprofile-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oprofile-list
Benjamin Herrenschmidt [off-list ref] wrote on 2011/11/25 06:24:32:
On Fri, 2011-11-18 at 09:22 +0100, Joakim Tjernlund wrote:
quoted
I forgot to ask, oprofile mentions setting -no-omit-framepointer to get
correct backtrace but I cannot turn on frame pointers for the ppc kernel.
Isn't frame pointers needed for pcc? what about user space?
PowerPC always has frame pointers, ignore that :-)
A bit late but consider this:
int leaf(int x)
{
return x+3;
}
which yields(with gcc -O2 -S):
.file "leaf.c"
.section ".text"
.align 2
.globl leaf
.type leaf, @function
leaf:
addi 3,3,3
blr
.size leaf, .-leaf
.section .note.GNU-stack,"",@progbits
.ident "GCC: (GNU) 3.4.6 (Gentoo 3.4.6-r2, ssp-3.4.6-1.0, pie-8.7.9)"
Here there is with frame pointer(I guess that the messing around with r11 and r31 is a defect?):
(With gcc -O2 -S -fno-omit-frame-pointer)
.file "leaf.c"
.section ".text"
.align 2
.globl leaf
.type leaf, @function
leaf:
stwu 1,-16(1)
addi 3,3,3
lwz 11,0(1)
stw 31,12(1)
mr 31,1
lwz 31,-4(11)
mr 1,11
blr
.size leaf, .-leaf
.section .note.GNU-stack,"",@progbits
.ident "GCC: (GNU) 3.4.6 (Gentoo 3.4.6-r2, ssp-3.4.6-1.0, pie-8.7.9)"
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2011-12-05 09:01:49
On Mon, 2011-12-05 at 09:50 +0100, Joakim Tjernlund wrote:
Benjamin Herrenschmidt [off-list ref] wrote on 2011/11/25 06:24:32:
quoted
On Fri, 2011-11-18 at 09:22 +0100, Joakim Tjernlund wrote:
quoted
I forgot to ask, oprofile mentions setting -no-omit-framepointer to get
correct backtrace but I cannot turn on frame pointers for the ppc kernel.
Isn't frame pointers needed for pcc? what about user space?
PowerPC always has frame pointers, ignore that :-)
A bit late but consider this:
.../...
Right I wasn't clear. We do have frame pointers for non-leaf functions,
and we can trace from LR when we are on a leaf function, we can use
__builtin_return_address as well.
We also explicitely prevent -fno-omit-frame-pointer, iirc, due to a bug
with older versions of gcc which could cause miscompiles under some
circumstances (though I don't remember the details).
Cheers,
Ben.
int leaf(int x)
{
return x+3;
}
which yields(with gcc -O2 -S):
.file "leaf.c"
.section ".text"
.align 2
.globl leaf
.type leaf, @function
leaf:
addi 3,3,3
blr
.size leaf, .-leaf
.section .note.GNU-stack,"",@progbits
.ident "GCC: (GNU) 3.4.6 (Gentoo 3.4.6-r2, ssp-3.4.6-1.0, pie-8.7.9)"
Here there is with frame pointer(I guess that the messing around with r11 and r31 is a defect?):
(With gcc -O2 -S -fno-omit-frame-pointer)
.file "leaf.c"
.section ".text"
.align 2
.globl leaf
.type leaf, @function
leaf:
stwu 1,-16(1)
addi 3,3,3
lwz 11,0(1)
stw 31,12(1)
mr 31,1
lwz 31,-4(11)
mr 1,11
blr
.size leaf, .-leaf
.section .note.GNU-stack,"",@progbits
.ident "GCC: (GNU) 3.4.6 (Gentoo 3.4.6-r2, ssp-3.4.6-1.0, pie-8.7.9)"