[RFC 1/2] ftrace porting of ia64

[RFC 1/2] ftrace porting of ia64

[Shaohua Li]

ftrace porting of IA64.
TBD:
1. I don't how to add unwind info to the assemble code, so please
advise.
2. The generic ftrace ring buffer code doesn't handle alignment well.
With the patch, kernel will report a lot of unalignment. This is still
under investigation.

Signed-off-by: Shaohua Li <shaohua.li@intel.com>
---
 arch/ia64/Kconfig              |    1 
 arch/ia64/include/asm/ftrace.h |   14 +++++++++++
 arch/ia64/kernel/entry.S       |   49 +++++++++++++++++++++++++++++++++++++++++
 arch/ia64/kernel/ia64_ksyms.c  |    6 +++++
 4 files changed, 70 insertions(+)

Index: linux/arch/ia64/Kconfig
=================================--- linux.orig/arch/ia64/Kconfig	2008-12-17 11:13:49.000000000 +0800
+++ linux/arch/ia64/Kconfig	2008-12-17 17:14:49.000000000 +0800
@@ -21,6 +21,7 @@ config IA64
 	select HAVE_OPROFILE
 	select HAVE_KPROBES
 	select HAVE_KRETPROBES
+	select HAVE_FUNCTION_TRACER
 	select HAVE_DMA_ATTRS
 	select HAVE_KVM
 	select HAVE_ARCH_TRACEHOOK
Index: linux/arch/ia64/include/asm/ftrace.h
=================================--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux/arch/ia64/include/asm/ftrace.h	2008-12-17 17:14:49.000000000 +0800
@@ -0,0 +1,15 @@
+#ifndef _ASM_IA64_FTRACE_H
+#define _ASM_IA64_FTRACE_H
+
+#ifdef CONFIG_FUNCTION_TRACER
+#define MCOUNT_INSN_SIZE        32 /* sizeof mcount call */
+
+#ifndef __ASSEMBLY__
+extern void _mcount(unsigned long pfs, unsigned long r1, unsigned long b0, unsigned long r0);
+#define mcount _mcount
+
+#endif
+
+#endif /* CONFIG_FUNCTION_TRACER */
+
+#endif /* _ASM_IA64_FTRACE_H */
Index: linux/arch/ia64/kernel/entry.S
=================================--- linux.orig/arch/ia64/kernel/entry.S	2008-12-17 11:13:49.000000000 +0800
+++ linux/arch/ia64/kernel/entry.S	2008-12-17 17:14:45.000000000 +0800
@@ -47,6 +47,7 @@
 #include <asm/processor.h>
 #include <asm/thread_info.h>
 #include <asm/unistd.h>
+#include <asm/ftrace.h>
 
 #include "minstate.h"
 
@@ -1404,6 +1405,54 @@ GLOBAL_ENTRY(unw_init_running)
 	br.ret.sptk.many rp
 END(unw_init_running)
 
+#ifdef CONFIG_FUNCTION_TRACER
+GLOBAL_ENTRY(_mcount)
+	movl r2 = ftrace_stub
+	movl r3 = ftrace_trace_function;;
+	ld8 r3 = [r3];;
+	ld8 r3 = [r3];;
+	cmp.eq p7,p0 = r2, r3
+(p7)	br.sptk.many ftrace_stub
+	;;
+
+	alloc loc0 = ar.pfs, 4, 4, 2, 0
+	;;
+	mov loc1 = b0
+	mov out0 = b0
+	mov loc2 = r8
+	mov loc3 = r15
+	;;
+	adds out0 = -MCOUNT_INSN_SIZE, out0
+	mov out1 = in2
+	mov b6 = r3
+
+	br.call.sptk.many b0 = b6
+	;;
+	mov ar.pfs = loc0
+	mov b0 = loc1
+	mov r8 = loc2
+	mov r15 = loc3
+	br ftrace_stub
+	;;
+END(_mcount)
+
+GLOBAL_ENTRY(ftrace_stub)
+	mov r3 = b0
+	movl r2 = _mcount_ret_helper
+	;;
+	mov b6 = r2
+	mov b7 = r3
+	br.ret.sptk.many b6
+
+_mcount_ret_helper:
+	mov b0 = r42
+	mov r1 = r41
+	mov ar.pfs = r40
+	br b7
+END(ftrace_stub)
+
+#endif /* CONFIG_FUNCTION_TRACER */
+
 	.rodata
 	.align 8
 	.globl sys_call_table
Index: linux/arch/ia64/kernel/ia64_ksyms.c
=================================--- linux.orig/arch/ia64/kernel/ia64_ksyms.c	2008-12-17 11:13:49.000000000 +0800
+++ linux/arch/ia64/kernel/ia64_ksyms.c	2008-12-17 13:16:51.000000000 +0800
@@ -112,3 +112,9 @@ EXPORT_SYMBOL_GPL(esi_call_phys);
 #endif
 extern char ia64_ivt[];
 EXPORT_SYMBOL(ia64_ivt);
+
+#include <asm/ftrace.h>
+#ifdef CONFIG_FUNCTION_TRACER
+/* mcount is defined in assembly */
+EXPORT_SYMBOL(_mcount);
+#endif

Re: [RFC 1/2] ftrace porting of ia64

[Ingo Molnar]

* Shaohua Li <shaohua.li@intel.com> wrote:

> ftrace porting of IA64.
> TBD:
> 1. I don't how to add unwind info to the assemble code, so please
> advise.
> 2. The generic ftrace ring buffer code doesn't handle alignment well.
> With the patch, kernel will report a lot of unalignment. This is still
> under investigation.

hm, that's weird - i recently profiled 64-bit x86 for unaligned accesses 
and there didnt seem to be many. In any case, feel free to fix any 
unaligned structure fields by reordering them.

	Ingo

Re: [RFC 1/2] ftrace porting of ia64

[Steven Rostedt]

On Thu, 2008-12-18 at 11:25 +0100, Ingo Molnar wrote:
> * Shaohua Li <shaohua.li@intel.com> wrote:
> 
> > ftrace porting of IA64.
> > TBD:
> > 1. I don't how to add unwind info to the assemble code, so please
> > advise.
> > 2. The generic ftrace ring buffer code doesn't handle alignment well.
> > With the patch, kernel will report a lot of unalignment. This is still
> > under investigation.
> 
> hm, that's weird - i recently profiled 64-bit x86 for unaligned accesses 
> and there didnt seem to be many. In any case, feel free to fix any 
> unaligned structure fields by reordering them.

Will x86_64 break if something is aligned by 32 bits?

The records in the buffer use to be 64 bit aligned. They are now 32 bit
aligned. I wonder if we should make that alignment arch specific.

-- Steve

Re: [RFC 1/2] ftrace porting of ia64

[Ingo Molnar]

* Steven Rostedt <srostedt@redhat.com> wrote:

> 
> On Thu, 2008-12-18 at 11:25 +0100, Ingo Molnar wrote:
> > * Shaohua Li <shaohua.li@intel.com> wrote:
> > 
> > > ftrace porting of IA64.
> > > TBD:
> > > 1. I don't how to add unwind info to the assemble code, so please
> > > advise.
> > > 2. The generic ftrace ring buffer code doesn't handle alignment well.
> > > With the patch, kernel will report a lot of unalignment. This is still
> > > under investigation.
> > 
> > hm, that's weird - i recently profiled 64-bit x86 for unaligned accesses 
> > and there didnt seem to be many. In any case, feel free to fix any 
> > unaligned structure fields by reordering them.
> 
> Will x86_64 break if something is aligned by 32 bits?

No, but there are tools to detect misalignment as they happen. (there are 
CPU hw counters for access misalignment and kerneltop can profile based on 
that info :-)

> The records in the buffer use to be 64 bit aligned. They are now 32 bit 
> aligned. I wonder if we should make that alignment arch specific.

No, we should just align them to 64 bits and be done with it.

	Ingo

Re: [RFC 1/2] ftrace porting of ia64

[Steven Rostedt]

On Thu, 2008-12-18 at 15:28 +0100, Ingo Molnar wrote:
> * Steven Rostedt <srostedt@redhat.com> wrote:
> 
> > 
> > On Thu, 2008-12-18 at 11:25 +0100, Ingo Molnar wrote:
> > > * Shaohua Li <shaohua.li@intel.com> wrote:
> > > 
> > > > ftrace porting of IA64.
> > > > TBD:
> > > > 1. I don't how to add unwind info to the assemble code, so please
> > > > advise.
> > > > 2. The generic ftrace ring buffer code doesn't handle alignment well.
> > > > With the patch, kernel will report a lot of unalignment. This is still
> > > > under investigation.
> > > 
> > > hm, that's weird - i recently profiled 64-bit x86 for unaligned accesses 
> > > and there didnt seem to be many. In any case, feel free to fix any 
> > > unaligned structure fields by reordering them.
> > 
> > Will x86_64 break if something is aligned by 32 bits?
> 
> No, but there are tools to detect misalignment as they happen. (there are 
> CPU hw counters for access misalignment and kerneltop can profile based on 
> that info :-)
> 
> > The records in the buffer use to be 64 bit aligned. They are now 32 bit 
> > aligned. I wonder if we should make that alignment arch specific.
> 
> No, we should just align them to 64 bits and be done with it.

I originally had it 64 bit aligned, but a lot of people complained about
the wasted space. The minimum record was 8 bytes, but you could have a
12 byte record. This allows for more compact recording.

Hmm, the header is 32 bits. Maybe that's the problem. The data part
starts at the 32bit mark. Maybe it is not the alignment of the record,
but the alignment of where the data starts. If the size is small enough,
it might align to the 32bit boundary.

I'll have to look more into that.

-- Steve

Re: [RFC 1/2] ftrace porting of ia64

[Shaohua Li]

On Thu, 2008-12-18 at 23:31 +0800, Steven Rostedt wrote:
> On Thu, 2008-12-18 at 15:28 +0100, Ingo Molnar wrote:
> > * Steven Rostedt <srostedt@redhat.com> wrote:
> > 
> > > 
> > > On Thu, 2008-12-18 at 11:25 +0100, Ingo Molnar wrote:
> > > > * Shaohua Li <shaohua.li@intel.com> wrote:
> > > > 
> > > > > ftrace porting of IA64.
> > > > > TBD:
> > > > > 1. I don't how to add unwind info to the assemble code, so please
> > > > > advise.
> > > > > 2. The generic ftrace ring buffer code doesn't handle alignment well.
> > > > > With the patch, kernel will report a lot of unalignment. This is still
> > > > > under investigation.
> > > > 
> > > > hm, that's weird - i recently profiled 64-bit x86 for unaligned accesses 
> > > > and there didnt seem to be many. In any case, feel free to fix any 
> > > > unaligned structure fields by reordering them.
> > > 
> > > Will x86_64 break if something is aligned by 32 bits?
> > 
> > No, but there are tools to detect misalignment as they happen. (there are 
> > CPU hw counters for access misalignment and kerneltop can profile based on 
> > that info :-)
> > 
> > > The records in the buffer use to be 64 bit aligned. They are now 32 bit 
> > > aligned. I wonder if we should make that alignment arch specific.
> > 
> > No, we should just align them to 64 bits and be done with it.
> 
> I originally had it 64 bit aligned, but a lot of people complained about
> the wasted space. The minimum record was 8 bytes, but you could have a
> 12 byte record. This allows for more compact recording.
> 
> Hmm, the header is 32 bits. Maybe that's the problem. The data part
> starts at the 32bit mark. Maybe it is not the alignment of the record,
> but the alignment of where the data starts. If the size is small enough,
> it might align to the 32bit boundary.
> 
> I'll have to look more into that.
I port my patch to latest -tip, the unalignment issue seems disappear.

Thanks,
Shaohua

Re: [RFC 1/2] ftrace porting of ia64

[Ingo Molnar]

* Shaohua Li <shaohua.li@intel.com> wrote:

> On Thu, 2008-12-18 at 23:31 +0800, Steven Rostedt wrote:
> > On Thu, 2008-12-18 at 15:28 +0100, Ingo Molnar wrote:
> > > * Steven Rostedt <srostedt@redhat.com> wrote:
> > > 
> > > > 
> > > > On Thu, 2008-12-18 at 11:25 +0100, Ingo Molnar wrote:
> > > > > * Shaohua Li <shaohua.li@intel.com> wrote:
> > > > > 
> > > > > > ftrace porting of IA64.
> > > > > > TBD:
> > > > > > 1. I don't how to add unwind info to the assemble code, so please
> > > > > > advise.
> > > > > > 2. The generic ftrace ring buffer code doesn't handle alignment well.
> > > > > > With the patch, kernel will report a lot of unalignment. This is still
> > > > > > under investigation.
> > > > > 
> > > > > hm, that's weird - i recently profiled 64-bit x86 for unaligned accesses 
> > > > > and there didnt seem to be many. In any case, feel free to fix any 
> > > > > unaligned structure fields by reordering them.
> > > > 
> > > > Will x86_64 break if something is aligned by 32 bits?
> > > 
> > > No, but there are tools to detect misalignment as they happen. (there are 
> > > CPU hw counters for access misalignment and kerneltop can profile based on 
> > > that info :-)
> > > 
> > > > The records in the buffer use to be 64 bit aligned. They are now 32 bit 
> > > > aligned. I wonder if we should make that alignment arch specific.
> > > 
> > > No, we should just align them to 64 bits and be done with it.
> > 
> > I originally had it 64 bit aligned, but a lot of people complained about
> > the wasted space. The minimum record was 8 bytes, but you could have a
> > 12 byte record. This allows for more compact recording.
> > 
> > Hmm, the header is 32 bits. Maybe that's the problem. The data part
> > starts at the 32bit mark. Maybe it is not the alignment of the record,
> > but the alignment of where the data starts. If the size is small enough,
> > it might align to the 32bit boundary.
> > 
> > I'll have to look more into that.
> I port my patch to latest -tip, the unalignment issue seems disappear.

thanks for checking!

	Ingo