lkml.org 
[lkml]   [2005]   [Jun]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: PREEMPT_RT and I-PIPE: the numbers, take 3
On Wed, Jun 29, 2005 at 03:57:34PM -0700, Bill Huey wrote:
> 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.

Why should he compile with CONFIG_SMP when CONFIG_SMP is absolutely
unnecessary without preempt-RT?

If you're an embedded developer, and you're _not_ using preempt-RT, why
in your right mind would you compile your kernel with CONFIG_SMP
enabled if you've only 1 cpu and no SMP in the hardware?

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

On UP the overhead of the spinlocks is measurable but it doesn't have
such huge order of magnitude, so even if you would enable CONFIG_SMP
(which makes absolutely no sense since embedded developers have 1 cpu to
deal with), you'd still underperform greatly compared to only
CONFIG_SMP=y. So even if somebody could buy that the benchmark is unfair
with CONFIG_SMP=n, I can just tell you that comparing against
CONFIG_SMP=y isn't going to save preempt-rt.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-06-30 01:07    [W:0.110 / U:0.428 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site