Messages in this thread |  | | Subject | Kernel profiling patch for PPC architecture now available | Date | Fri, 18 Aug 2000 17:21:43 +1000 (EST) | From | (Graham Stoney) |
| |
I recently had the need to do some simple kernel profiling on PPC, and noticed that the collection of data for /proc/profile wasn't implemented for the PPC architecture. I've since added it, and published the following patch: http://members.xoom.com/greyhams/linux/patches/2.2/profile.patch
I'd be very grateful for any feedback you might have. Here's the header to whet the appetite:
/proc/profile support for ppc & arm in 2.2 Updated: 16 August 2000 ------------------------------------------ -----------------------
The following patch adds /proc/profile kernel profiling support in the Linux 2.2 series kernel to those architectures that currently lack it. Previously, ppc and arm had fallen through the cracks and didn't support this, so the info in /proc/profile was always zeros.
Kernel profiling works like this: each timer interrupt calls the do_profile function, and if the interrupt occurs during kernel code it increments a counter for each range of addresses. Profiling is enabled by the "profile=" option on the kernel command line, which also sets the granularity of data collected. The smaller the number, the finer the grain of data collected, and the more memory required for the data buffer. The user-space program "readprofile" then reads the profiling data from /proc/profile, and displays the data against kernel symbols read from System.map. Modules don't get profiled, sorry.
In the interest of reducing duplication, this patch hauls all the divergent do_profile implementations out from those architectures that did support it, and puts it in linux/sched.h where all architectures can see it.
I think the call to do_profile might be better moved to the architecture independent do_timer routine, to ensure that all new architectures also support profiling and prevent the problem which motivated this patch recurring. However, I'm not sure if this is correct for SMP machines and at least one architecture (sparc/ap1000) uses a seperate hardware tick other than the system timer to do profiling.
I don't know how well this works for SMP kernels, but it shouldn't be any worse than it was before. I can't see why write_profile only adjusts the profiling timer on SMP machines in fs/proc/array.c; perhaps the #ifdef test is backwards?
mips & sparc architectures had a CONFIG_PROFILE macro, but I couldn't see any definition of it, so I removed it. Perhaps I should add architecture-independent support for it in include/linux/sched.h?
Note that other people are working on adding full _mcount-based gprof profiling to the kernel, but generally only for the i386 architecture. I'm not planning on going to that extreme. For examples, see: http://oss.sgi.com/projects/kernprof/ ftp://ftp.suse.com/pub/people/andrea/kernel-patches/ikd/
I'm very keen to hear from anyone willing to give this a try, even on architectures that already supported /proc/profile, just to make sure I didn't break anything. If there's sufficient interest, I'll follow up with a 2.4 patch once this has been tested.
Please let me know what you think! -- Graham Stoney Principal Hardware/Software Engineer Canon Information Systems Research Australia Ph: +61 2 9805 2909 Fax: +61 2 9805 2929
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |