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

["Paul E. McKenney" <paulmck@us.ibm.com>]

On Wed, Jun 29, 2005 at 03:57:34PM -0700, Bill Huey wrote:
> 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.

If you were suggesting this to be run on an SMP system, I would agree
with you.  I, too, would very much like to see these results run on a
2-CPU or 4-CPU system, although I am most certainly -not- asking Kristian
and Karim to do this work -- it is very much someone else's turn in the
barrel, I would say!

However, on a UP system, I have to agree with Kristian's choice of
configuration.  An embedded system developer running on a UP system would
naturally use a UP Linux kernel build, so it makes sense to benchmark
a UP kernel on a UP system.

						Thanx, Paul