From: Remi S. <rs...@wy...> - 2010-08-23 13:06:28
|
Hello all. I would like to make an estimation about the efforts I could need to port oProfile to another architecture, SH4. Is it as complex as Valgrind ? How long hours do you think is needed for this ? Is someone interested in starting such a project ? Thanks. Regards. -- Rémi SAVOYE EPITA 2010 GISTR WyPlay ---- This message contains confidential information and may contain information that is legally privileged. If you have received this message by mistake, please immediately notify us and delete the original message. Thank you. Ce message contient des informations confidentielles. S'il vous est parvenu par erreur, merci de bien vouloir nous en aviser par retour, de n'en faire aucun usage et de n'en garder aucune copie. ---- |
From: William C. <wc...@re...> - 2010-08-23 14:31:54
|
On 08/23/2010 08:42 AM, Remi Savoye wrote: > Hello all. > > I would like to make an estimation about the efforts I could need to port oProfile to another architecture, SH4. > > Is it as complex as Valgrind ? > How long hours do you think is needed for this ? > Is someone interested in starting such a project ? > > Thanks. > Regards. Hi Remi, In theory oprofile should work in timer mode on most processors with little or no work. There appears to be some support alread in the kernel SH processor. Looking at the arch/sh/Kconfig in the upstream kernels there is a line in the SUPERH section of the file: select HAVE_OPROFILE If possible you, see if the oprofile in timer mode is sufficient. That should be the quickest and easiest way to make use of oprofile on SH processor. Check to see if there is a CONFIG_OPROFILE=y or CONFIG_OPROFILE=m in the kernel config file. If it isn't there try to build a kernel with CONFIG_OPROFILE=y or CONFIG_OPROFILE=m. Access to the actual performance monitoring hardware on the processor would require more work. However, it would be less involved that Valgrind. Valgrind has to understand the instructions to take them apart, insert instrumentation, and generate new instructions. OProfile needs to have something identify the processor type in the kernel, code to set up performance monitoring hardware, and handle the interrupts created by the performance monitoring hardware. The user space needs lists to map the event names to numbers. The rest of oprofile generically handles the transport of samples from kernel to user space and mapping the samples to the executable code. -Will PS I don't know how much experience you have with the kernel. If you are looking for more information to get familiar with the kernel, the site http://kernelnewbies.org/ is helpful. |
From: Xavier R. <xav...@st...> - 2010-08-24 11:38:36
|
Hi Remi, We (at STMicroelectronics) have already do the job, and afaik it was quite easy. I guess you're working with ST, isn't it ? If you are using STLinux, you have probably all the stuff ready to use. Xavier Raynaud -----Original Message----- From: Remi Savoye [mailto:rs...@wy...] Sent: lundi 23 août 2010 14:42 To: opr...@li... Subject: Porting oProfile to SH4 Hello all. I would like to make an estimation about the efforts I could need to port oProfile to another architecture, SH4. Is it as complex as Valgrind ? How long hours do you think is needed for this ? Is someone interested in starting such a project ? Thanks. Regards. -- Rémi SAVOYE EPITA 2010 GISTR WyPlay ---- This message contains confidential information and may contain information that is legally privileged. If you have received this message by mistake, please immediately notify us and delete the original message. Thank you. Ce message contient des informations confidentielles. S'il vous est parvenu par erreur, merci de bien vouloir nous en aviser par retour, de n'en faire aucun usage et de n'en garder aucune copie. ---- ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ oprofile-list mailing list opr...@li... https://lists.sourceforge.net/lists/listinfo/oprofile-list |
From: William C. <wc...@re...> - 2010-08-24 13:56:42
|
On 08/24/2010 07:37 AM, Xavier RAYNAUD wrote: > Hi Remi, > > We (at STMicroelectronics) have already do the job, and afaik it was quite easy. > I guess you're working with ST, isn't it ? If you are using STLinux, you have probably all the stuff ready to use. > > Xavier Raynaud Hi Xavier, I was going to ask if there was some information on how to use OProfile on STLinux, but I found a writeup at: http://www.stlinux.com/devel/traceprofile/profiling -Will |
From: Will D. <wil...@ar...> - 2010-08-26 14:07:14
|
> On 08/24/2010 07:37 AM, Xavier RAYNAUD wrote: > > Hi Remi, > > > > We (at STMicroelectronics) have already do the job, and afaik it was quite easy. > > I guess you're working with ST, isn't it ? If you are using STLinux, you have probably all the stuff > ready to use. > > > > Xavier Raynaud > > Hi Xavier, > > I was going to ask if there was some information on how to use OProfile on STLinux, but I found a > writeup at: > > http://www.stlinux.com/devel/traceprofile/profiling > There's currently some work in the Kernel to move the SH Oprofile backend to perf, in the same way as was done for ARM: http://lkml.org/lkml/2010/8/23/116 If you have a recent enough Kernel, you might be better off adding perf support (although I thought SH was already supported) and then using the OProfile client above. The userspace additions to OProfile should be fairly trivial. Cheers, Will [a different one!] |
From: Maynard J. <may...@us...> - 2010-08-27 14:36:40
|
Will Deacon wrote: >> On 08/24/2010 07:37 AM, Xavier RAYNAUD wrote: >>> Hi Remi, >>> >>> We (at STMicroelectronics) have already do the job, and afaik it was quite easy. >>> I guess you're working with ST, isn't it ? If you are using STLinux, you have probably all the stuff >> ready to use. >>> >>> Xavier Raynaud >> >> Hi Xavier, >> >> I was going to ask if there was some information on how to use OProfile on STLinux, but I found a >> writeup at: >> >> http://www.stlinux.com/devel/traceprofile/profiling >> > > There's currently some work in the Kernel to move the SH > Oprofile backend to perf, in the same way as was done for ARM: > > http://lkml.org/lkml/2010/8/23/116 Very interesting. I don't have time to follow everything on LKML, so I appreciate you pointing out this conversation. *Robert*, I believe you were cc'ed on this, so when you enter the conversation, please add oprofile-list to cc to keep the community informed. IIRC, this sort of step-wise transition to perf_events was something you argued for in the past. I'll be curious to see how the broader kernel community reviews this patch series. One thing I would like to point out about this patch. The counter_config[i].event (which is used to set the perf_event_attr.config value) is retrieved from the oprofilefs "event" file. This does not work for all architectures -- notably, ppc64 (maybe others?). Currently, the event value is not even used in the ppc64 oprofile kernel driver; instead, there are some additional files created in oprofilefs that are used for counter configurationo (mmcr0, mmcr1, mmcra). So, for the time being, ppc64 would not be able to use this new code. Redesigning oprofile userspace to take full advantage of perf_events (adding per-process profiling, using the perf_event fd to mmap the sample buffer vs using the existing event buffer) will be a non-trivial task. This is something I would like to see happen in the near future. Other responsibilities have prevented me from spending time on this, but it's high on my priority list. If anyone else in the community would like to submit an RFC, I'd be happy to help review it. But if someone does want to do this (whether me or someone else), they should give a heads-up to the oprofile community to try to prevent duplicate efforts. -Maynard > > If you have a recent enough Kernel, you might be better off > adding perf support (although I thought SH was already supported) > and then using the OProfile client above. > > The userspace additions to OProfile should be fairly trivial. > > Cheers, > > Will [a different one!] > > > > ------------------------------------------------------------------------------ > Sell apps to millions through the Intel(R) Atom(Tm) Developer Program > Be part of this innovative community and reach millions of netbook users > worldwide. Take advantage of special opportunities to increase revenue and > speed time-to-market. Join now, and jumpstart your future. > http://p.sf.net/sfu/intel-atom-d2d > _______________________________________________ > oprofile-list mailing list > opr...@li... > https://lists.sourceforge.net/lists/listinfo/oprofile-list |
From: Robert R. <rob...@am...> - 2010-08-27 15:23:27
|
On 27.08.10 10:36:16, Maynard Johnson wrote: > Will Deacon wrote: > > There's currently some work in the Kernel to move the SH > > Oprofile backend to perf, in the same way as was done for ARM: > > > > http://lkml.org/lkml/2010/8/23/116 > Very interesting. I don't have time to follow everything on LKML, > so I appreciate you pointing out this conversation. *Robert*, I > believe you were cc'ed on this, so when you enter the conversation, > please add oprofile-list to cc to keep the community informed. > IIRC, this sort of step-wise transition to perf_events was something > you argued for in the past. I'll be curious to see how the broader > kernel community reviews this patch series. I just reviewed the patches and the approach looks good, but we will have some respins with the patches. I will cc the oprofile-list with my next replies. There are already patches for arm upstream, this patch set makes it generic oprofile code allowing each architecture that supports perf also to use oprofile. In general I think that kernel people are waiting for this already for a long time. We will have less subsystem collisions and less duplicate work, perf users will benefit from oprofile features esp. in the userland. So I think there will be much support for this implementation. > Redesigning oprofile userspace to take full advantage of perf_events > (adding per-process profiling, using the perf_event fd to mmap the > sample buffer vs using the existing event buffer) will be a > non-trivial task. This is something I would like to see happen in > the near future. Other responsibilities have prevented me from > spending time on this, but it's high on my priority list. If anyone > else in the community would like to submit an RFC, I'd be happy to > help review it. But if someone does want to do this (whether me or > someone else), they should give a heads-up to the oprofile community > to try to prevent duplicate efforts. The kernel work is the first step of integrating perf and oprofile. A port of the oprofile daemon to use the perf syscall will be another (additional) step, which would make the oprofile kernel driver in some time obsolete. This will be the best technical solution also reducing duplicate kernel work for perf and oprofile. -Robert -- Advanced Micro Devices, Inc. Operating System Research Center |