Kprobes for ARM testing and performance

[Quentin Barnes]

I didn't mention any drawbacks to my Kprobes for ARM limitations
in my previous mail.  The biggest one is that there are a lot of
decision paths in decoding and rewriting the instructions which
means a large potential for latent bugs.  The code needs a lot of
testing and probably needs to have a custom test suite written for
it.  In the mean time, I've hack ported systemtap/testsuite to ARM.
I've got it mostly there and working except for the stack traceback
and a couple of other pieces.

Most of the tests pass.  Some of them don't.  Some of the failures
are known problems with the tests and current kernels.  Some of them
are differences between ARM and other the platforms.  Other ones I
haven't analyzed yet.

I'll be posting my ARM port work to systemtap runtime and testsuite
to the mailing list at some point.  One of the problems I ran across
is running the tests on a slower processor often timed out.  I had
to change many of the hardcoded timeouts in the tests.  Is there a
better way to deal with this?


I did gather some performance numbers using Jim Keniston's timing
code.  For a 364.00MHz XScale-PXA270 with a system bus clock at
104.00MHz running 5,000,000 iterations:
======
ktime	630 jiffies    1.26us

jtime   1586 jiffies   3.17us

rtime   1724 jiffies   3.45us

krtime  1943 jiffies   3.89us

jrtime  2986 jiffies   5.97us
======

Quentin