[lkml]   [2000]   [Aug]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectKernel profiling patch for PPC architecture now available
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:

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 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:

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
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:37    [W:2.058 / U:0.004 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site