Firstly, make sure you have both the I and D caches enabled!
Also, make sure you have serialization disabled (Set ICTRL to 0x7).
To get maximum performance, you need to enable copyback data cache. This can be disabled in order to make the standard Linux/PPC libraries work without recompiling. If you build your own glibc as described under Runtime Library, you can enable copyback. Look for a "make config" option, or grep for DC_SFWT in
arch/ppc/kernel/head.Sand change the
#if 0to
#if 1.
The BogoMIPS value on 8xx processors should be within 1% or so of the actual CPU core frequency, allowing for rounding & minor timing calculation errors. This makes it a useful sanity check to verify that the internal clock multiplier is set correctly, and that the I-cache is turned on. However, note that the calculation of the BogoMIPS value is still tied to the external clock source and internal prescaler settings, so it shouldn't be solely relied on to verify that the core frequency really is what you think it should be. A simple cross-check is to perform a 'sleep 10' at the shell prompt, and time it with a watch to check that you're at least in the ballpark. It's wise to measure your system more accurately than this with a CRO at least once.
Also, beware that the BogoMIPS rating should not be used as a general CPU performance measure; see: http://linuxdoc.org/HOWTO/mini/BogoMips.html
There are numerous options available for system profiling, depending on what you wish to measure, and how invasive you are prepared to be.
/proc/profile is a standard kernel feature which provides simple kernel profiling based on Instruction Pointer sampling in the periodic timer interrupt routine. It's simplistic but effective, and low overhead since the interrupt is going to happen anyway. The data is processed with readprofile which looks up the System.map to show which kernel functions are using the most CPU time. It doesn't work for modules yet so at present you need to compile them in for profiling.
You need to enable this at boot time by passing profile=2 on the command line; The number gives the power of 2 granularity used for the counters -- 2 will give you a seperate counter for each PowerPC instruction (each 4 bytes). Higher numbers consume less memory and give less precise results. The data from /proc/profile will be in target byte order, so if you're cross-developing you may need to either byte swap it, or compile readprofile to run on your target.
The PowerPC branch of the Linux kernel has been slow to implement the Instruction Pointer sampling function necessary to generate the /proc/profile data. If it isn't implemented in your kernel, you'll see that readprofile always shows zero time for every kernel function. In this case you need to apply the profile.patch from: http://members.xoom.com/greyhams/linux/patches/
The Linux Trace Toolkit works with an instrumented Linux kernel by saving time-stamped records of important kernel events to a binary data file. A data decoder converts the binary data to text and calculates statistical summaries, such as percent processor utilization by each process. The toolkit also includes an integrated environment that graphically displays the results and provides search capability.
A version for embedded PowerPC targets is now available from: ftp://ftp.mvista.com/pub/LTT.
All the usual Linux user mode profiling tools like gprof are available.
http://oss.sgi.com/projects/kernprof
This project aims to make full gprof profiling available for the kernel. However, it hasn't been ported to the PowerPC architecture yet.
Beware that IDMA on the 860 is not designed for high performance, and the CPU gets better throughput with explicit cache bursted programmed I/O. Search for IDMA for more discussion.
Confusion sometimes arises because DMA transfers in most systems are faster than CPU transfers, whereas here the reverse is generally true. Furthermore, IDMA transfers eat into CPM processing time, limiting throughput on other communications modules at the same time.
To get good TCP/IP performance, you need a fast CPU. Using the FEC, a 50 MHz 860P will run about 30 Mbits/sec TCP/IP, and a 100 MHz 860P will run about 60 Mbits/sec TCP/IP. The bottleneck is the protocol and application processing in the PPC core. The performance of a TCP/IP connection scales nearly linearly with the processor speed.
If you need to go faster, use the 8260.
Optimising everything for space using gcc's -Os option is likely to provide both the smallest code size and best performance, because it inhibits loop unrolling optimisation which tends to have a negative effect on embedded processors with relatively small cache sizes. Furthermore, PowerPC processors can speculatively execute branches overlapped with other loop instructions, making the branch effectively execute in zero cycles so loop unrolling is unnecessary in many circumstances.