From: F. <jrf...@tu...> - 2007-11-20 22:50:16
|
Hi, I wrote a script to generate a time-colored call graph from oprofile output, using graphviz. The script available from http://code.google.com/p/jrfonseca/wiki/Gprof2Dot . See an output example of profiling glxgears on Gallium 3D ( http://www.tungstengraphics.com/wiki/index.php/Gallium3D ) on http://people.freedesktop.org/~jrfonseca/profiling/oprofile-gallium.png . The hotter the colour of a function is, more time is spent on that function and its children. José Fonseca |
From: John L. <le...@mo...> - 2007-11-21 09:09:09
|
On Tue, Nov 20, 2007 at 10:45:17PM +0000, José Fonseca wrote: > http://people.freedesktop.org/~jrfonseca/profiling/oprofile-gallium.png Neat! regards john |
From: Santos, J. R. G <jos...@hp...> - 2007-12-05 23:04:48
Attachments:
xen_reserve_domain_switch_code.patch
|
John, As per our previous discussion, here is a patch to reserve the escape code = for Xen domain switch. Thanks Renato |
From: William C. <wc...@re...> - 2007-12-06 22:10:09
|
The older xenoprof patch adds some defines to oprofile/daemon/opd_interface.h. Unfortunately, these defines conflict with the defines added for the Cell processor in oprofile 0.9.3: #define SPU_PROFILING_CODE 11 #define SPU_CTX_SWITCH_CODE 12 This conflicts older xenoprof patch: +#define DOMAIN_SWITCH_CODE 11 +#define LAST_CODE 12 The newer patch reserves the XEN_DOMAIN_SWITCH_CODE for xenoprof's use with a different value. I have been thinking how to handle these in a flexible manner in oprofile and made a table listing out the meaning of each of the values mentioned in opd_interface.h: old new proposed xenoprof patch stock xenoprof patch 0.9.2 0.9.3 >0.9.3 0 - - - 1 CTX_SWITCH_CODE CTX_SWITCH_CODE " 2 CPU_SWITCH_CODE CPU_SWITCH_CODE " 3 COOKIE_SWITCH_CODE COOKIE_SWITCH_CODE " 4 KERNEL_ENTER_SWITCH_CODE KERNEL_ENTER_SWITCH_CODE" 5 USER_ENTER_SWITCH_CODE USER_ENTER_SWITCH_CODE " 6 MODULE_LOADED_CODE MODULE_LOADED_CODE " 7 CTX_TGID_CODE CTX_TGID_CODE " 8 TRACE_BEGIN_CODE TRACE_BEGIN_CODE " 9 /* unused */ /* unused */ " 10 XEN_ENTER_SWITCH_CODE XEN_ENTER_SWITCH_CODE XEN_ENTER_SWITCH_CODE 11 DOMAIN_SWITCH_CODE SPU_PROFILING_CODE SPU_PROFILING_CODE 12 LAST_CODE SPU_CTX_SWITCH_CODE SPU_CTX_SWITCH_CODE 13 LAST_CODE XEN_DOMAIN_SWITCH_CODE 14 LAST_CODE Turns out the defines in opd_interface.h are never really used anywhere. There is a function table that used to map the numbers to the appropriate action. If xen will never run on ppc, then could modify opd_trans.c entry for SPU_CTX_SWITCH_CODE to XEN_ENTER_SWITCH_CODE on non ppc machines and have addition entry at handlers[13] for XEN_DOMAIN_SWITCH_CODE. This should allow both the old and new version of xen profiling data to be understood. handler_t handlers[LAST_CODE + 1] = { &code_unknown, &code_ctx_switch, &code_cpu_switch, &code_cookie_switch, &code_kernel_enter, &code_user_enter, &code_module_loaded, /* tgid handled differently */ &code_unknown, &code_trace_begin, &code_unknown, &code_xen_enter, #if defined(__ppc__) || defined(__ppc64__) &code_spu_profiling, #else &code_domain_switch, #endif &code_spu_ctx_switch, &code_domain_switch, }; Is this a workable solution? Do people have comments on this approach to getting oprofile to work with old and new versions of xenoprof? -Will |
From: John L. <le...@mo...> - 2007-12-06 22:24:38
|
On Thu, Dec 06, 2007 at 05:09:58PM -0500, William Cohen wrote: > Turns out the defines in opd_interface.h are never really used > anywhere. There is a function table that used to map the numbers to > the appropriate action. If xen will never run on ppc, then could > modify opd_trans.c entry for SPU_CTX_SWITCH_CODE to > XEN_ENTER_SWITCH_CODE on non ppc machines and have addition entry at Unfortunately, Xen does run on PPC (though I'm not so sure about Cell!). It sounds like something has to break, and it's going to have to be Xen. regards john |
From: Santos, J. R. G <jos...@hp...> - 2007-12-06 22:35:06
|
I don't think this will work. It turns out that Xen already runs on PPC (http://xenbits.xensource.com/e= xt/xenppc-unstable.hg). PPC Xen does not have Oprofile support yet, but I expect that it will be = added in the future. Hollis Blanchard is the mantainer of Xen for PPC Any comments Hollis? What are your plans for adding Oprofile support? Renato > -----Original Message----- > From: William Cohen [mailto:wc...@re...] > Sent: Thursday, December 06, 2007 2:10 PM > To: Santos, Jose Renato G > Cc: Markus Armbruster; opr...@li... > Subject: Re: [PATCH] reserve Xen passive domain switch escape code > > The older xenoprof patch adds some defines to > oprofile/daemon/opd_interface.h. > Unfortunately, these defines conflict with the defines added > for the Cell processor in oprofile 0.9.3: > > > #define SPU_PROFILING_CODE 11 > #define SPU_CTX_SWITCH_CODE 12 > > This conflicts older xenoprof patch: > > > +#define DOMAIN_SWITCH_CODE 11 > +#define LAST_CODE 12 > > The newer patch reserves the XEN_DOMAIN_SWITCH_CODE for > xenoprof's use with a different value. I have been thinking > how to handle these in a flexible manner in oprofile and made > a table listing out the meaning of each of the values > mentioned in opd_interface.h: > > old new proposed > xenoprof patch stock xenoprof patch > 0.9.2 0.9.3 >0.9.3 > 0 - - - > 1 CTX_SWITCH_CODE CTX_SWITCH_CODE " > 2 CPU_SWITCH_CODE CPU_SWITCH_CODE " > 3 COOKIE_SWITCH_CODE COOKIE_SWITCH_CODE " > 4 KERNEL_ENTER_SWITCH_CODE KERNEL_ENTER_SWITCH_CODE" > 5 USER_ENTER_SWITCH_CODE USER_ENTER_SWITCH_CODE " > 6 MODULE_LOADED_CODE MODULE_LOADED_CODE " > 7 CTX_TGID_CODE CTX_TGID_CODE " > 8 TRACE_BEGIN_CODE TRACE_BEGIN_CODE " > 9 /* unused */ /* unused */ " > 10 XEN_ENTER_SWITCH_CODE XEN_ENTER_SWITCH_CODE > XEN_ENTER_SWITCH_CODE > 11 DOMAIN_SWITCH_CODE SPU_PROFILING_CODE > SPU_PROFILING_CODE > 12 LAST_CODE SPU_CTX_SWITCH_CODE > SPU_CTX_SWITCH_CODE > 13 LAST_CODE > XEN_DOMAIN_SWITCH_CODE > 14 LAST_CODE > > Turns out the defines in opd_interface.h are never really > used anywhere. There is a function table that used to map the > numbers to the appropriate action. If xen will never run on > ppc, then could modify opd_trans.c entry for > SPU_CTX_SWITCH_CODE to XEN_ENTER_SWITCH_CODE on non ppc > machines and have addition entry at handlers[13] for > XEN_DOMAIN_SWITCH_CODE. This should allow both the old and > new version of xen profiling data to be understood. > > handler_t handlers[LAST_CODE + 1] =3D { > &code_unknown, > &code_ctx_switch, > &code_cpu_switch, > &code_cookie_switch, > &code_kernel_enter, > &code_user_enter, > &code_module_loaded, > /* tgid handled differently */ > &code_unknown, > &code_trace_begin, > &code_unknown, > &code_xen_enter, > #if defined(__ppc__) || defined(__ppc64__) > &code_spu_profiling, > #else > &code_domain_switch, > #endif > &code_spu_ctx_switch, > &code_domain_switch, > }; > > Is this a workable solution? Do people have comments on this > approach to getting oprofile to work with old and new > versions of xenoprof? > > -Will > > |
From: Markus A. <ar...@re...> - 2007-12-07 07:20:05
|
John Levon <le...@mo...> writes: > On Thu, Dec 06, 2007 at 05:09:58PM -0500, William Cohen wrote: > >> Turns out the defines in opd_interface.h are never really used >> anywhere. There is a function table that used to map the numbers to >> the appropriate action. If xen will never run on ppc, then could >> modify opd_trans.c entry for SPU_CTX_SWITCH_CODE to >> XEN_ENTER_SWITCH_CODE on non ppc machines and have addition entry at > > Unfortunately, Xen does run on PPC (though I'm not so sure about Cell!). > > It sounds like something has to break, and it's going to have to be Xen. > > regards > john Well, Xen doesn't *have* to break, if we're willing to accept a certain (moderate) degree of ugliness. The new codes are only for PPC, where Xenoprof doesn't quite exist yet. Therefore, we can stick to the old codes on platforms that have Xenoprof already, and use the new ones everywhere else. Something like this: #define XEN_ENTER_SWITCH_CODE 10 #if defined(__i386__) || defined(__x86_64__) #define DOMAIN_SWITCH_CODE 11 #define LAST_CODE 12 #else #define SPU_PROFILING_CODE 11 #define SPU_CTX_SWITCH_CODE 12 #define DOMAIN_SWITCH_CODE 13 #define LAST_CODE 14 #endif |
From: John L. <le...@mo...> - 2007-12-07 13:02:11
|
On Fri, Dec 07, 2007 at 08:19:53AM +0100, Markus Armbruster wrote: > The new codes are only for PPC, where Xenoprof doesn't quite exist > yet. Therefore, we can stick to the old codes on platforms that have > Xenoprof already, and use the new ones everywhere else. Something > like this: Good point. Let's do this. It's ugly as sin but better than breaking people's machines. Nice big comment though please... regards john |
From: Hollis B. <ho...@us...> - 2007-12-11 16:27:21
|
I don't currently have plans to add oprofile support to PowerPC Xen, but obviously we shouldn't actively prevent people from doing it in the future... -- Hollis Blanchard IBM Linux Technology Center On Thu, 2007-12-06 at 22:28 +0000, Santos, Jose Renato G wrote: > I don't think this will work. > It turns out that Xen already runs on PPC (http://xenbits.xensource.com/ext/xenppc-unstable.hg). > PPC Xen does not have Oprofile support yet, but I expect that it will be added in the future. > Hollis Blanchard is the mantainer of Xen for PPC > Any comments Hollis? What are your plans for adding Oprofile support? > > Renato > > > -----Original Message----- > > From: William Cohen [mailto:wc...@re...] > > Sent: Thursday, December 06, 2007 2:10 PM > > To: Santos, Jose Renato G > > Cc: Markus Armbruster; opr...@li... > > Subject: Re: [PATCH] reserve Xen passive domain switch escape code > > > > The older xenoprof patch adds some defines to > > oprofile/daemon/opd_interface.h. > > Unfortunately, these defines conflict with the defines added > > for the Cell processor in oprofile 0.9.3: > > > > > > #define SPU_PROFILING_CODE 11 > > #define SPU_CTX_SWITCH_CODE 12 > > > > This conflicts older xenoprof patch: > > > > > > +#define DOMAIN_SWITCH_CODE 11 > > +#define LAST_CODE 12 > > > > The newer patch reserves the XEN_DOMAIN_SWITCH_CODE for > > xenoprof's use with a different value. I have been thinking > > how to handle these in a flexible manner in oprofile and made > > a table listing out the meaning of each of the values > > mentioned in opd_interface.h: > > > > old new proposed > > xenoprof patch stock xenoprof patch > > 0.9.2 0.9.3 >0.9.3 > > 0 - - - > > 1 CTX_SWITCH_CODE CTX_SWITCH_CODE " > > 2 CPU_SWITCH_CODE CPU_SWITCH_CODE " > > 3 COOKIE_SWITCH_CODE COOKIE_SWITCH_CODE " > > 4 KERNEL_ENTER_SWITCH_CODE KERNEL_ENTER_SWITCH_CODE" > > 5 USER_ENTER_SWITCH_CODE USER_ENTER_SWITCH_CODE " > > 6 MODULE_LOADED_CODE MODULE_LOADED_CODE " > > 7 CTX_TGID_CODE CTX_TGID_CODE " > > 8 TRACE_BEGIN_CODE TRACE_BEGIN_CODE " > > 9 /* unused */ /* unused */ " > > 10 XEN_ENTER_SWITCH_CODE XEN_ENTER_SWITCH_CODE > > XEN_ENTER_SWITCH_CODE > > 11 DOMAIN_SWITCH_CODE SPU_PROFILING_CODE > > SPU_PROFILING_CODE > > 12 LAST_CODE SPU_CTX_SWITCH_CODE > > SPU_CTX_SWITCH_CODE > > 13 LAST_CODE > > XEN_DOMAIN_SWITCH_CODE > > 14 LAST_CODE > > > > Turns out the defines in opd_interface.h are never really > > used anywhere. There is a function table that used to map the > > numbers to the appropriate action. If xen will never run on > > ppc, then could modify opd_trans.c entry for > > SPU_CTX_SWITCH_CODE to XEN_ENTER_SWITCH_CODE on non ppc > > machines and have addition entry at handlers[13] for > > XEN_DOMAIN_SWITCH_CODE. This should allow both the old and > > new version of xen profiling data to be understood. > > > > handler_t handlers[LAST_CODE + 1] = { > > &code_unknown, > > &code_ctx_switch, > > &code_cpu_switch, > > &code_cookie_switch, > > &code_kernel_enter, > > &code_user_enter, > > &code_module_loaded, > > /* tgid handled differently */ > > &code_unknown, > > &code_trace_begin, > > &code_unknown, > > &code_xen_enter, > > #if defined(__ppc__) || defined(__ppc64__) > > &code_spu_profiling, > > #else > > &code_domain_switch, > > #endif > > &code_spu_ctx_switch, > > &code_domain_switch, > > }; > > > > Is this a workable solution? Do people have comments on this > > approach to getting oprofile to work with old and new > > versions of xenoprof? > > > > -Will > > > > |
From: Maynard J. <may...@us...> - 2008-01-11 18:01:17
|
Hollis Blanchard wrote: > I don't currently have plans to add oprofile support to PowerPC Xen, but > obviously we shouldn't actively prevent people from doing it in the > future... > Hollis, A change was just committed to oprofile userspace to work around this collision. The ramification of this change is that when oprofile support is added to PowerPC Xen, it can NOT use the same DOMAIN_SWITCH_CODE as the Intel Xen; it must use '13'. I've pasted the contents of the file below for your reference. Regards, Maynard Johnson /** * @file opd_interface.h * * Module / user space interface for 2.6 kernels and above * * @remark Copyright 2002 OProfile authors * @remark Read the file COPYING * * @author John Levon * @author Philippe Elie * Modified by Aravind Menon for Xen * These modifications are: * Copyright (C) 2005 Hewlett-Packard Co. */ #ifndef OPD_INTERFACE_H #define OPD_INTERFACE_H #define CTX_SWITCH_CODE 1 #define CPU_SWITCH_CODE 2 #define COOKIE_SWITCH_CODE 3 #define KERNEL_ENTER_SWITCH_CODE 4 #define USER_ENTER_SWITCH_CODE 5 #define MODULE_LOADED_CODE 6 #define CTX_TGID_CODE 7 #define TRACE_BEGIN_CODE 8 /* Code 9 used to be TRACE_END_CODE which is not used anymore */ /* Code 9 is now considered an unknown escape code */ #define XEN_ENTER_SWITCH_CODE 10 /* * Ugly work-around for the unfortunate collision between Xenoprof's * DOMAIN_SWITCH_CODE (in use on x86) and Cell's SPU_PROFILING_CODE * (in use with Power): */ #if defined(__powerpc__) #define SPU_PROFILING_CODE 11 #define SPU_CTX_SWITCH_CODE 12 #define DOMAIN_SWITCH_CODE 13 #define LAST_CODE 14 #else #define DOMAIN_SWITCH_CODE 11 #define LAST_CODE 12 #endif #endif /* OPD_INTERFACE_H */ |
From: Markus A. <ar...@re...> - 2007-12-13 13:19:13
|
John Levon <le...@mo...> writes: > On Fri, Dec 07, 2007 at 08:19:53AM +0100, Markus Armbruster wrote: > >> The new codes are only for PPC, where Xenoprof doesn't quite exist >> yet. Therefore, we can stick to the old codes on platforms that have >> Xenoprof already, and use the new ones everywhere else. Something >> like this: > > Good point. Let's do this. It's ugly as sin but better than breaking > people's machines. Nice big comment though please... > > regards > john Here's a patch for that. Tested on i686 bare metal. Signed-off-by: Markus Armbruster <ar...@re...> Index: daemon/opd_interface.h =================================================================== RCS file: /cvsroot/oprofile/oprofile/daemon/opd_interface.h,v retrieving revision 1.6 diff -p -u -w -r1.6 opd_interface.h --- a/daemon/opd_interface.h 10 May 2007 23:42:33 -0000 1.6 +++ b/daemon/opd_interface.h 12 Dec 2007 19:51:44 -0000 @@ -27,8 +27,19 @@ /* Code 9 used to be TRACE_END_CODE which is not used anymore */ /* Code 9 is now considered an unknown escape code */ #define XEN_ENTER_SWITCH_CODE 10 +/* + * Ugly work-around for the unfortunate collision between Xenoprof's + * DOMAIN_SWITCH_CODE (in use on x86) and Cell's SPU_PROFILING_CODE + * (in use with Power): + */ +#if defined(__i386__) || defined(__x86_64__) +#define DOMAIN_SWITCH_CODE 11 +#define LAST_CODE 12 +#else #define SPU_PROFILING_CODE 11 #define SPU_CTX_SWITCH_CODE 12 -#define LAST_CODE 13 +#define DOMAIN_SWITCH_CODE 13 +#define LAST_CODE 14 +#endif #endif /* OPD_INTERFACE_H */ Index: daemon/opd_trans.c =================================================================== RCS file: /cvsroot/oprofile/oprofile/daemon/opd_trans.c,v retrieving revision 1.16 diff -p -u -w -r1.16 opd_trans.c --- a/daemon/opd_trans.c 10 May 2007 23:42:33 -0000 1.16 +++ b/daemon/opd_trans.c 12 Dec 2007 19:51:45 -0000 @@ -271,8 +271,11 @@ handler_t handlers[LAST_CODE + 1] = { &code_trace_begin, &code_unknown, &code_xen_enter, +#if !defined(__i386__) && !defined(__x86_64__) &code_spu_profiling, &code_spu_ctx_switch, +#endif + &code_unknown, }; extern void (*special_processor)(struct transient *); |
From: Markus A. <ar...@re...> - 2008-01-11 15:05:14
|
Did this fall through the cracks? Markus Armbruster <ar...@re...> writes: > John Levon <le...@mo...> writes: > >> On Fri, Dec 07, 2007 at 08:19:53AM +0100, Markus Armbruster wrote: >> >>> The new codes are only for PPC, where Xenoprof doesn't quite exist >>> yet. Therefore, we can stick to the old codes on platforms that have >>> Xenoprof already, and use the new ones everywhere else. Something >>> like this: >> >> Good point. Let's do this. It's ugly as sin but better than breaking >> people's machines. Nice big comment though please... >> >> regards >> john > > Here's a patch for that. Tested on i686 bare metal. > > Signed-off-by: Markus Armbruster <ar...@re...> > > Index: daemon/opd_interface.h > =================================================================== > RCS file: /cvsroot/oprofile/oprofile/daemon/opd_interface.h,v > retrieving revision 1.6 > diff -p -u -w -r1.6 opd_interface.h > --- a/daemon/opd_interface.h 10 May 2007 23:42:33 -0000 1.6 > +++ b/daemon/opd_interface.h 12 Dec 2007 19:51:44 -0000 > @@ -27,8 +27,19 @@ > /* Code 9 used to be TRACE_END_CODE which is not used anymore */ > /* Code 9 is now considered an unknown escape code */ > #define XEN_ENTER_SWITCH_CODE 10 > +/* > + * Ugly work-around for the unfortunate collision between Xenoprof's > + * DOMAIN_SWITCH_CODE (in use on x86) and Cell's SPU_PROFILING_CODE > + * (in use with Power): > + */ > +#if defined(__i386__) || defined(__x86_64__) > +#define DOMAIN_SWITCH_CODE 11 > +#define LAST_CODE 12 > +#else > #define SPU_PROFILING_CODE 11 > #define SPU_CTX_SWITCH_CODE 12 > -#define LAST_CODE 13 > +#define DOMAIN_SWITCH_CODE 13 > +#define LAST_CODE 14 > +#endif > > #endif /* OPD_INTERFACE_H */ > Index: daemon/opd_trans.c > =================================================================== > RCS file: /cvsroot/oprofile/oprofile/daemon/opd_trans.c,v > retrieving revision 1.16 > diff -p -u -w -r1.16 opd_trans.c > --- a/daemon/opd_trans.c 10 May 2007 23:42:33 -0000 1.16 > +++ b/daemon/opd_trans.c 12 Dec 2007 19:51:45 -0000 > @@ -271,8 +271,11 @@ handler_t handlers[LAST_CODE + 1] = { > &code_trace_begin, > &code_unknown, > &code_xen_enter, > +#if !defined(__i386__) && !defined(__x86_64__) > &code_spu_profiling, > &code_spu_ctx_switch, > +#endif > + &code_unknown, > }; > > extern void (*special_processor)(struct transient *); |
From: John L. <le...@mo...> - 2008-01-11 16:49:02
|
On Fri, Jan 11, 2008 at 04:05:08PM +0100, Markus Armbruster wrote: > Did this fall through the cracks? Yes. Applied now, thanks. regards john |
From: Isaku Y. <yam...@va...> - 2008-01-15 01:50:46
|
On Fri, Jan 11, 2008 at 04:48:35PM +0000, John Levon wrote: > On Fri, Jan 11, 2008 at 04:05:08PM +0100, Markus Armbruster wrote: > > > Did this fall through the cracks? > > Yes. Applied now, thanks. The change to opd_trans.c isn't consistent with the one to opd_interface.h. The ifdef clause should be "#if defined(__powerpc__)" (or "#if !defined(__i386__) && !defined(__x86_64__) && !defined(__ia64__)") in both opd_trans.c and opd_interface.h. Index: daemon/opd_trans.c =================================================================== RCS file: /cvsroot/oprofile/oprofile/daemon/opd_trans.c,v retrieving revision 1.17 diff -u -p -r1.17 opd_trans.c --- daemon/opd_trans.c 11 Jan 2008 17:49:24 -0000 1.17 +++ daemon/opd_trans.c 15 Jan 2008 01:42:34 -0000 @@ -271,7 +271,7 @@ handler_t handlers[LAST_CODE + 1] = { &code_trace_begin, &code_unknown, &code_xen_enter, -#if !defined(__i386__) && !defined(__x86_64__) +#if defined(__powerpc__) &code_spu_profiling, &code_spu_ctx_switch, #endif -- yamahata |
From: John L. <le...@mo...> - 2008-01-15 02:06:17
|
On Tue, Jan 15, 2008 at 10:50:44AM +0900, Isaku Yamahata wrote: > The change to opd_trans.c isn't consistent with the one to > opd_interface.h. Thanks, fixed regards john |