public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* RE: 2.6.19-rt14 slowdown compared to 2.6.19
@ 2006-12-27  0:51 Chen, Tim C
  2006-12-29 23:26 ` [PATCH] lock stat for -rt 2.6.20-rc2-rt2 [was Re: 2.6.19-rt14 slowdown compared to 2.6.19] Bill Huey
  0 siblings, 1 reply; 25+ messages in thread
From: Chen, Tim C @ 2006-12-27  0:51 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel, Siddha, Suresh B, Peter Zijlstra

Ingo Molnar wrote:
> 
> cool - thanks for the feedback! Running the 64-bit kernel, right?
> 

Yes, 64-bit kernel was used.

> 
> while some slowdown is to be expected, did in each case idle time
> increase significantly? 

Volanomark and Re-Aim7 ran close to 0% idle time for 2.6.19 kernel.
Idle time
increase significantly for Volanomark (to 60% idle) and Re-Aim7 (to 20%
idle) 
with the rt kernel.  For netperf, the system was 60% idle for 
both 2.6.19 and rt kernel and changes in idle time was not significant.

> If yes then this is the effect of lock
> contention. Lock contention effects are 'magnified' by PREEMPT_RT. For
> example if you run 128 threads workload that all use the same lock
> then 
> the -rt kernel can act as if it were a 128-way box (!). This way by
> running -rt you'll see scalability problems alot sooner than on real
> hardware. In other words: PREEMPT_RT in essence simulates the
> scalability behavior of up to an infinite amount of CPUs. (with the
> exception of cachemiss emulation ;) [the effect is not this precise,
> but 
> that's the rough trend]

Turning off PREEMPT_RT for 2.6.20-rc2-rt0 kernel
restored most the performance of Volanaomark
and Re-Aim7.  Idle time is close to 0%.  So the benchmarks
with large number of threads are affected more by PREEMPT_RT.

For netperf TCP streaming, the performance improved from 40% down to 20%
down from 2.6.20-rc2 kernel.  There is only a server and a client
process
for netperf.  The underlying reason for the change in performance
is probably different.

> 
> If you'd like to profile this yourself then the lowest-cost way of
> profiling lock contention on -rt is to use the yum kernel and run the
> attached trace-it-lock-prof.c code on the box while your workload is
> in 'steady state' (and is showing those extended idle times):
> 
>   ./trace-it-lock-prof > trace.txt
> 

Thanks for the pointer.  Will let you know of any relevant traces.

Thanks.

Tim

^ permalink raw reply	[flat|nested] 25+ messages in thread

end of thread, other threads:[~2007-01-25  8:41 UTC | newest]

Thread overview: 25+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-12-27  0:51 2.6.19-rt14 slowdown compared to 2.6.19 Chen, Tim C
2006-12-29 23:26 ` [PATCH] lock stat for -rt 2.6.20-rc2-rt2 [was Re: 2.6.19-rt14 slowdown compared to 2.6.19] Bill Huey
2006-12-30 11:19   ` Ingo Molnar
2006-12-30 14:56     ` Daniel Walker
2006-12-30 19:32       ` Bill Huey
2007-01-03  7:41     ` [PATCH] lock stat for -rt 2.6.20-rc2-rt2.2.lock_stat.patch Bill Huey
2007-01-03 23:59       ` Chen, Tim C
2007-01-04  0:12         ` Bill Huey
2007-01-04  0:25           ` Chen, Tim C
2007-01-04  0:29             ` Bill Huey
2007-01-04  0:46               ` Chen, Tim C
2007-01-04  1:00                 ` Bill Huey
2007-01-04  1:07                   ` Bill Huey
2007-01-04  1:11                   ` Chen, Tim C
2007-01-04  1:27                     ` Bill Huey
2007-01-04  2:14                       ` Chen, Tim C
2007-01-04  8:12                         ` Bill Huey
2007-01-04  4:46       ` Ingo Molnar
2007-01-24 23:06         ` Bill Huey
2007-01-25  8:39           ` Ingo Molnar
2007-01-24 11:31       ` Ingo Molnar
2007-01-24 22:52         ` Bill Huey
2007-01-02 22:51   ` [PATCH] lock stat for -rt 2.6.20-rc2-rt2 [was Re: 2.6.19-rt14 slowdown compared to 2.6.19] Chen, Tim C
2007-01-02 23:12     ` Bill Huey
2007-01-02 23:47       ` Bill Huey

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox