Re: PREEMPT_RT and I-PIPE: the numbers, take 3

[Bill Huey (hui) <bhuey@lnxw.com>]

On Wed, Jun 29, 2005 at 06:29:24PM -0400, Kristian Benoit wrote:
> Overall analysis:
...
> We had not intended to redo a 3rd run so early, but we're happy we did
> given the doubts expressed by some on the LKML. And as we suspected, these
> new results very much corroborate what we had found earlier. As such, our
> conclusions remain mostly unchanged:

Did you compile your host Linux kernel with CONFIG_SMP in place ? That's
critical since a UP kernel removes both spinlock and blocking locks in
critical paths makes micro benchmarks sort of invalid.

The benchmark is sort of confusing two things and merging them into one.
Both the latency statistic and kernel performance must be kept seperate.
The overall kernel performance is a more complicate issue that has to be
analysize differently using a more complicated methodology. That because
an RTOS use of PREEMPT_RT is going to be under a different circumstance
than that of a pure dual kernel set up of some sort. The functionalities
aren't the same.

I suggest that you compile the dual kernel with SMP turned on and try it
again, otherwise it's not really testing the overhead of any of the locking
for either the PREEMPT_RT or dual kernel set ups. That's really the only
outstanding statistic that I've noticed in that benchmark.

bill