From: Dave J. <dj...@ya...> - 2003-12-22 18:12:12
|
I'm looking into getting Oprofile running on the XScale architecture (ARM). What is needed to do this? Can oprofile be enabled without arch specific code or do I need to create an oprofile dir under arch/arm/ and put in necessary support code? Thanks! --------------------------------- Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing |
From: William C. <wc...@nc...> - 2003-12-22 19:43:15
Attachments:
oprofporting.txt
|
Dave Jiang wrote: > I'm looking into getting Oprofile running on the XScale architecture > (ARM). What is needed to do this? Can oprofile be enabled without arch > specific code or do I need to create an oprofile dir under arch/arm/ and > put in necessary support code? Thanks! OProfile needs to be integrated into each new architecture. The amount of code that needed to be added is relatively small at this point. In some earlier email I wrote up some steps porting OProfile to new architectures. I have attached the earlier email to this message. This should outline what needs to be done. There are probably some changes since this was written, e.g. the consolidation of the code for the timer interrupt data. I don't know which kernel you are planning on doing the working, 2.4 or 2.6. It would be preferable to do the work in the 2.6 kernel. If the work has to go into a 2.4 kernel,you might use the backport Red Hat has in its kernel to provide the 2.6 oprofile kernel support in a 2.4 kernel. The one caution is the patch is missing the pointer_size in the /dev/oprofile, so the development verions of OProfile won't work with the the backport. -Will |
From: Dave J. <dj...@ya...> - 2003-12-22 20:29:26
|
It will be 2.6. I hope I can get it working and send a patch to RMK for the ARM tree. =) William Cohen <wc...@nc...> wrote:Dave Jiang wrote: > I'm looking into getting Oprofile running on the XScale architecture > (ARM). What is needed to do this? Can oprofile be enabled without arch > specific code or do I need to create an oprofile dir under arch/arm/ and > put in necessary support code? Thanks! OProfile needs to be integrated into each new architecture. The amount of code that needed to be added is relatively small at this point. In some earlier email I wrote up some steps porting OProfile to new architectures. I have attached the earlier email to this message. This should outline what needs to be done. There are probably some changes since this was written, e.g. the consolidation of the code for the timer interrupt data. I don't know which kernel you are planning on doing the working, 2.4 or 2.6. It would be preferable to do the work in the 2.6 kernel. If the work has to go into a 2.4 kernel,you might use the backport Red Hat has in its kernel to provide the 2.6 oprofile kernel support in a 2.4 kernel. The one caution is the patch is missing the pointer_size in the /dev/oprofile, so the development verions of OProfile won't work with the the backport. -Will Subject: Steps to port oprofile to new architecture From: William Cohen Date: Wed, 16 Jul 2003 11:02:19 -0400 To: oprofile-list I wrote up a simple outline of steps to provide basic TIMER_INT OProfile support to the 2.5 kernel. Comments on them? I would think this would be something that would end up in an "OProfile Internals" manual. -Will List of things need to do for minimal oprofile timer interrupt support for platform for 2.5 kernel 1) create arch/processor/oprofile directory 2) put arch/processor/oprofile/Makefile arch/processor/oprofile/Kconfig arch/processor/oprofile/init.c 3) Add to arch/processor/Kconfig just before "Kernel hacking" section: source "arch/processor/oprofile/Kconfig" 4) Add to arch/processor/Makefile: # must be linked after kernel/ drivers-$(CONFIG_OPROFILE) += arch/processor/oprofile/ 5) Modify arch/processor/kernel/timer.c to record oprofile samples 6) Adding support for lookup_dcookie. Add __NR_lookup_dcookie entry to include/asm-processor/unistd.h May also need additional support in arch/processor/kernel for processors that have 64-bit kernel and 32-bit user space, e.g. ppc64. Need to add lookup_dcookie entry to syscall table. 7) For older 2.4 kernel you will need to implement cpu_possible() for the oprofile driver. 8) For the user space oprofile need to add appropriate __NR_lookup_dcookie to oprofile/daemon/opd_cookie.h ------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 _______________________________________________ oprofile-list mailing list opr...@li... https://lists.sourceforge.net/lists/listinfo/oprofile-list --------------------------------- Do you Yahoo!? Yahoo! Photos - Get your photo on the big screen in Times Square |
From: Dave J. <dj...@ya...> - 2003-12-22 20:38:07
|
Question regarding the attached instructions. #5 Modify arch/processor/kernel/timer.c to record oprofile sampels. Are there existing examples or is that just the do_profile function in all the existing archs? William Cohen <wc...@nc...> wrote:Dave Jiang wrote: > I'm looking into getting Oprofile running on the XScale architecture > (ARM). What is needed to do this? Can oprofile be enabled without arch > specific code or do I need to create an oprofile dir under arch/arm/ and > put in necessary support code? Thanks! OProfile needs to be integrated into each new architecture. The amount of code that needed to be added is relatively small at this point. In some earlier email I wrote up some steps porting OProfile to new architectures. I have attached the earlier email to this message. This should outline what needs to be done. There are probably some changes since this was written, e.g. the consolidation of the code for the timer interrupt data. I don't know which kernel you are planning on doing the working, 2.4 or 2.6. It would be preferable to do the work in the 2.6 kernel. If the work has to go into a 2.4 kernel,you might use the backport Red Hat has in its kernel to provide the 2.6 oprofile kernel support in a 2.4 kernel. The one caution is the patch is missing the pointer_size in the /dev/oprofile, so the development verions of OProfile won't work with the the backport. -Will Subject: Steps to port oprofile to new architecture From: William Cohen Date: Wed, 16 Jul 2003 11:02:19 -0400 To: oprofile-list I wrote up a simple outline of steps to provide basic TIMER_INT OProfile support to the 2.5 kernel. Comments on them? I would think this would be something that would end up in an "OProfile Internals" manual. -Will List of things need to do for minimal oprofile timer interrupt support for platform for 2.5 kernel 1) create arch/processor/oprofile directory 2) put arch/processor/oprofile/Makefile arch/processor/oprofile/Kconfig arch/processor/oprofile/init.c 3) Add to arch/processor/Kconfig just before "Kernel hacking" section: source "arch/processor/oprofile/Kconfig" 4) Add to arch/processor/Makefile: # must be linked after kernel/ drivers-$(CONFIG_OPROFILE) += arch/processor/oprofile/ 5) Modify arch/processor/kernel/timer.c to record oprofile samples 6) Adding support for lookup_dcookie. Add __NR_lookup_dcookie entry to include/asm-processor/unistd.h May also need additional support in arch/processor/kernel for processors that have 64-bit kernel and 32-bit user space, e.g. ppc64. Need to add lookup_dcookie entry to syscall table. 7) For older 2.4 kernel you will need to implement cpu_possible() for the oprofile driver. 8) For the user space oprofile need to add appropriate __NR_lookup_dcookie to oprofile/daemon/opd_cookie.h ------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 _______________________________________________ oprofile-list mailing list opr...@li... https://lists.sourceforge.net/lists/listinfo/oprofile-list --------------------------------- Do you Yahoo!? Yahoo! Photos - Get your photo on the big screen in Times Square |
From: William C. <wc...@nc...> - 2003-12-22 20:47:39
|
You should be able to look at the ia64 or ppc64 in the 2.6 kernels as examples. -Will Dave Jiang wrote: > Question regarding the attached instructions. #5 Modify > arch/processor/kernel/timer.c to record oprofile sampels. Are there > existing examples or is that just the do_profile function in all the > existing archs? > > */William Cohen <wc...@nc...>/* wrote: > > Dave Jiang wrote: > > I'm looking into getting Oprofile running on the XScale architecture > > (ARM). What is needed to do this? Can oprofile be enabled without > arch > > specific code or do I need to create an oprofile dir under > arch/arm/ and > > put in necessary support code? Thanks! > > OProfile needs to be integrated into each new architecture. The amount > of code that needed to be added is relatively small at this point. In > some earlier email I wrote up some steps porting OProfile to new > architectures. I have attached the earlier email to this message. This > should outline what needs to be done. There are probably some changes > since this was written, e.g. the consolidation of the code for the > timer > interrupt data. > > I don't know which kernel you are planning on doing the working, 2.4 or > 2.6. It would be preferable to do! the work in the 2.6 kernel. If the > work has to go into a 2.4 kernel,you might use the backport Red Hat has > in its kernel to provide the 2.6 oprofile kernel support in a 2.4 > kernel. The one caution is the patch is missing the pointer_size in the > /dev/oprofile, so the development verions of OProfile won't work with > the the backport. > > -Will > Subject: > Steps to port oprofile to new architecture > From: > William Cohen > Date: > Wed, 16 Jul 2003 11:02:19 -0400 > To: > oprofile-list > > I wrote up a simple outline of steps to provide basic TIMER_INT > OProfile support to the 2.5 kernel. Comments on them? I would think > this would be something that would end up in an "OProfile Internals" > manual. > > -Will > > > > List of things need to do for minimal oprofile timer interrupt support > for platform for 2.5 kernel > > 1) create arch/processor/oprofile directory > 2) put arch/processor/oprofile/Makefile > arch/processor/oprofile/Kconfig > arch/processor/oprofile/init.c > 3) Add to arch/processor/Kconfig just before "Kernel hacking" section: > > source "arch/processor/oprofile/Kconfig" > > 4) Add to arch/processor/Makefile: > > # must be linked after kernel/ > drivers-$(CONFIG_OPROFILE) += arch/processor/oprofile/ > > > 5) Modify arch/processor/kernel/timer.c to record oprofile samples > > 6) Adding support for lookup_dcookie. > Add __NR_lookup_dcookie entry to include/asm-processor/unistd.h > May also need additional support in arch/processor/kernel for > processors that have 64-bit kernel and 32-bit user space, e.g. ppc64. > Need to add lookup_dcookie entry to syscall table. > > > 7) For older 2.4 kernel you will need to implement cpu_possible() for > the oprofile driver. > > > 8) For the user space oprofile need to add appropriate > __NR_lookup_dcookie to oprofile/daemon/opd_cookie.h > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: VM Ware > With VMware you can run multiple operating systems on a single machine. > WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the > same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 > _______________________________________________ > oprofile-list mailing list > opr...@li... > https://lists.sourceforge.net/lists/listinfo/oprofile-list > > ------------------------------------------------------------------------ > Do you Yahoo!? > Yahoo! Photos - Get your photo on the big screen in Times Square > <http://us.rd.yahoo.com/evt=21486/*http://f1.pg.photos.yahoo.com/ph//spsimplenol?.file=ny_ts_splash.html> > |
From: Philippe E. <ph...@wa...> - 2003-12-22 20:37:52
|
Dave Jiang wrote: > I'm looking into getting Oprofile running on the XScale architecture > (ARM). What is needed to do this? Can oprofile be enabled without arch > specific code or do I need to create an oprofile dir under arch/arm/ and > put in necessary support code? Thanks! Zwane, didn't you plan to suppport XScale ? regards, Phil |
From: Zwane M. <zw...@ar...> - 2003-12-22 21:51:26
Attachments:
oprofile-xscale.tar.bz2
|
On Mon, 22 Dec 2003, John Levon wrote: > On Mon, Dec 22, 2003 at 10:12:12AM -0800, Dave Jiang wrote: > > > I'm looking into getting Oprofile running on the XScale architecture > > (ARM). What is needed to do this? Can oprofile be enabled without arch > > specific code or do I need to create an oprofile dir under arch/arm/ > > and put in necessary support code? Thanks! Hullo Dave, John. here is what i have so far, it doesn't compile again due to some changes but it should be good for a general idea of how things should go (i've discussed parts of it with John already). Dave the arch code may have errors as this has never been run before. > Talk to Zwane, he has an (unfinished) patch. Perhaps you could help him, > he can't get 2.6 running on his ARM box. Thanks |
From: Dave J. <dj...@ya...> - 2003-12-22 22:02:07
|
Thanks Zwane. I briefly looked over your attachment. It looks like a PXA patch (XScale) for the PMU support right? Have you been able to get it working with the generic stuff yet? Like hooking the oprofile in the timer interrupt and etc? I'm hoping to get it working with the generic stuff before looking into providing more arch specific support..... The ARM/XScale arch is somewhat different than the other major archs due to so many variations and they all use their own timer_interrupt routines..... Zwane Mwaikambo <zw...@ar...> wrote:On Mon, 22 Dec 2003, John Levon wrote: > On Mon, Dec 22, 2003 at 10:12:12AM -0800, Dave Jiang wrote: > > > I'm looking into getting Oprofile running on the XScale architecture > > (ARM). What is needed to do this? Can oprofile be enabled without arch > > specific code or do I need to create an oprofile dir under arch/arm/ > > and put in necessary support code? Thanks! Hullo Dave, John. here is what i have so far, it doesn't compile again due to some changes but it should be good for a general idea of how things should go (i've discussed parts of it with John already). Dave the arch code may have errors as this has never been run before. > Talk to Zwane, he has an (unfinished) patch. Perhaps you could help him, > he can't get 2.6 running on his ARM box. Thanks > ATTACHMENT part 2 application/x-bzip2 name=oprofile-xscale.tar.bz2 --------------------------------- Do you Yahoo!? Yahoo! Photos - Get your photo on the big screen in Times Square |
From: Zwane M. <zw...@ar...> - 2003-12-22 22:18:47
|
On Mon, 22 Dec 2003, Dave Jiang wrote: > Thanks Zwane. I briefly looked over your attachment. It looks like a PXA > patch (XScale) for the PMU support right? Have you been able to get it > working with the generic stuff yet? Like hooking the oprofile in the timer > interrupt and etc? I'm hoping to get it working with the generic stuff > before looking into providing more arch specific support..... The > ARM/XScale arch is somewhat different than the other major archs due to > so many variations and they all use their own timer_interrupt > routines..... Oh, no i haven't tried that, but that shouldn't be too difficult, can't you determine the machine specific timer routine at compile time? |
From: Dave J. <dj...@ya...> - 2003-12-22 22:25:23
|
Yes, I'm just saying that in order to support all ARM or XScale targets, you have to do it for each platform instead of a single generic place.... Anyways, I'm not sure if I'm hooking in the correct call. Right now I'm calling the do_profile() function from ARM's time.h.... Is that the one used by oprofile? Zwane Mwaikambo <zw...@ar...> wrote:On Mon, 22 Dec 2003, Dave Jiang wrote: > Thanks Zwane. I briefly looked over your attachment. It looks like a PXA > patch (XScale) for the PMU support right? Have you been able to get it > working with the generic stuff yet? Like hooking the oprofile in the timer > interrupt and etc? I'm hoping to get it working with the generic stuff > before looking into providing more arch specific support..... The > ARM/XScale arch is somewhat different than the other major archs due to > so many variations and they all use their own timer_interrupt > routines..... Oh, no i haven't tried that, but that shouldn't be too difficult, can't you determine the machine specific timer routine at compile time? --------------------------------- Do you Yahoo!? Yahoo! Photos - Get your photo on the big screen in Times Square |
From: Zwane M. <zw...@ar...> - 2003-12-22 22:30:29
|
On Mon, 22 Dec 2003, Dave Jiang wrote: > Yes, I'm just saying that in order to support all ARM or XScale targets, > you have to do it for each platform instead of a single generic place.... > Anyways, I'm not sure if I'm hooking in the correct call. Right now I'm > calling the do_profile() function from ARM's time.h.... Is that the one > used by oprofile? oprofile_add_sample() would be what you want. |
From: Dave J. <dj...@ya...> - 2003-12-22 23:52:40
|
Not sure why but when I do "opcontrol --reset" it just sits there forever. Zwane Mwaikambo <zw...@ar...> wrote:On Mon, 22 Dec 2003, Dave Jiang wrote: > Yes, I'm just saying that in order to support all ARM or XScale targets, > you have to do it for each platform instead of a single generic place.... > Anyways, I'm not sure if I'm hooking in the correct call. Right now I'm > calling the do_profile() function from ARM's time.h.... Is that the one > used by oprofile? oprofile_add_sample() would be what you want. --------------------------------- Do you Yahoo!? Yahoo! Photos - Get your photo on the big screen in Times Square |
From: William C. <wc...@nc...> - 2003-12-23 00:31:36
|
Dave Jiang wrote: > Not sure why but when I do "opcontrol --reset" it just sits there forever. Is the daemon dying when you do "opcontrol --reset"? The "opcontrol --reset" does a dump of the data before erasing it. It is likly the opcontrol script is waiting for a change on the date of /var/lib/oprofile/compete_dump. No daemon, no change in date, and the script never exits. -Will > > */Zwane Mwaikambo <zw...@ar...>/* wrote: > > On Mon, 22 Dec 2003, Dave Jiang wrote: > > > Yes, I'm just saying that in order to support all ARM or XScale > targets, > > you have to do it for each platform instead of a single generic > place.... > > Anyways, I'm not sure if I'm hooking in the correct call. Right > now I'm > > calling the do_profile() function from ARM's time.h.... Is that > the one > > used by oprofile? > > oprofile_add_sample() would be what you want. > > ------------------------------------------------------------------------ > Do you Yahoo!? > Yahoo! Photos - Get your photo on the big screen in Times Square > <http://us.rd.yahoo.com/evt=21486/*http://f1.pg.photos.yahoo.com/ph//spsimplenol?.file=ny_ts_splash.html> > |
From: Dave J. <dj...@ya...> - 2003-12-23 00:49:44
|
William Cohen <wc...@nc...> wrote: Dave Jiang wrote: > Not sure why but when I do "opcontrol --reset" it just sits there forever. Is the daemon dying when you do "opcontrol --reset"? The "opcontrol --reset" does a dump of the data before erasing it. It is likly the opcontrol script is waiting for a change on the date of /var/lib/oprofile/compete_dump. No daemon, no change in date, and the script never exits. -Will Well, the daemon does not disappear, however if I "touch" the complete_file the operation completes. This is also the case for --stop. The rootfs is nfs mounted, that shouldn't be a problem right? --------------------------------- Do you Yahoo!? Yahoo! Photos - Get your photo on the big screen in Times Square |
From: William C. <wc...@nc...> - 2003-12-23 01:01:45
|
Dave Jiang wrote: > */William Cohen <wc...@nc...>/* wrote: > > Dave Jiang wrote: > > Not sure why but when I do "opcontrol --reset" it just sits there > forever. > > Is the daemon dying when you do "opcontrol --reset"? The "opcontrol > --reset" does a dump of the data before erasing it. It is likly the > opcontrol script is waiting for a change on the date of > /var/lib/oprofile/compete_dump. No daemon, no change in date, and the > script never exits. > > -Will > > Well, the daemon does not disappear, however if I "touch" the > complete_file the operation completes. This is also the case for --stop. > The rootfs is nfs mounted, that shouldn't be a problem right? Then the daemon is not changing /var/lib/oprofile/complete_dump. Is this on the X86 system? Or are you trying out the zwane's ARM port? It sounds like the /dev/oprofile/dump is not implement or not working in the kernel. Assuming that the file system works and allow root to access it, it shouldn't be a problem. Are 0ther files such as oprofile.log and lock being written in /var/lib/oprofile? Does the /dev/oprofile directory look reasonable? --reset, --dump, --stop, and --shutdown are going to have similar behavior. They all attempt to flush data from the kernel. -Will |
From: Dave J. <dj...@ya...> - 2003-12-23 16:08:08
|
William Cohen <wc...@nc...> wrote: Then the daemon is not changing /var/lib/oprofile/complete_dump. Is this on the X86 system? Or are you trying out the zwane's ARM port? It sounds like the /dev/oprofile/dump is not implement or not working in the kernel. Assuming that the file system works and allow root to access it, it shouldn't be a problem. Are 0ther files such as oprofile.log and lock being written in /var/lib/oprofile? Does the /dev/oprofile directory look reasonable? --reset, --dump, --stop, and --shutdown are going to have similar behavior. They all attempt to flush data from the kernel. -Will This is on an XScale (ARM) system. I haven't used anything from Zwane yet. I'm just trying to get the generic stuff working before I touch the arch specific things. The log file is being written to as far as I can tell. Also the lock file. Everything in /dev/oprofile looks okay to me... --------------------------------- Do you Yahoo!? Yahoo! Photos - Get your photo on the big screen in Times Square |
From: William C. <wc...@nc...> - 2003-12-23 17:08:38
|
Dave Jiang wrote: > > */William Cohen <wc...@nc...>/* wrote: > > > Then the daemon is not changing /var/lib/oprofile/complete_dump. Is > this > on the X86 system? Or are you trying out the zwane's ARM port? It > sounds > like the /dev/oprofile/dump is not implement or not working in the > kernel. Assuming that the file system works and allow root to access > it, > it shouldn't be a problem. Are 0ther files such as oprofile.log and > lock > being written in /var/lib/oprofile? Does the /dev/oprofile directory > look reasonable? > > --reset, --dump, --stop, and --shutdown are going to have similar > behavior. They all attempt to flush data from the kernel. > > > -Will > > > > This is on an XScale (ARM) system. I haven't used anything from Zwane > yet. I'm just trying to get the generic stuff working before I touch the > arch specific things. The log file is being written to as far as I can > tell. Also the lock file. Everything in /dev/oprofile looks okay to me... You might try starting the daemon (opcontrol) with --verbose and looking through /var/lib/oprofile/oprofiled.log to check to see whether any samples are being collected by the daemon. Taking a look files in /dev/oprofile/stats/ will show you whether the interrupts are being produced and samples are being collected by the kernel. -Will |