On Thu, Jul 10, 2008 at 09:50:47AM +0200, Wolfgang Grandegger wrote:

Luotao Fu wrote:

quoted

Hi Wolfgang,
On Wed, Jul 09, 2008 at 03:15:01PM +0200, Wolfgang Grandegger wrote:

quoted

Hi Fu (without n)

....

quoted

OK, in the past you have been able to reproduce the high latencies with  
2.6.24-rt1 and CONFIG_RCU_TRACE disabled, IIRC. Did you use a different  
toolchain at that time?

Nope. As mentioned above, trace_mark() does some "real" works (what ever 
it is.),
while the new mechahnismen use flags to remember the state of preemption. 
Maybe

I don't known what you refer to, but in __rcu_preempt_unboost() of 
2.6.25.8-rt7, the trace code simply increments a counter:

       static void rcu_trace_boost_##type(struct rcu_boost_dat *rbd)   \
       {                                                               \
               rbd->rbs_stat_##type++;                                 \
       }

and that's the reason why latency is not affected by switching 
CONFIG_RCU_TRACE
on (while trace_mark uses preempt_disable/preempt_enable around).

This changed -- preempt_disable()/preempt_enable() pair
was added for rcu_trace_boost_boost_called_preempt() and
rcu_trace_boost_unboost_called_preempt() later to suppress a warning
(and also make that statistic accurate in face of preemption).

						Thanx, Paul

quoted

something here got optimized away? I take for grant, that you use gcc in 
your
toolchain. Which version do you have?

The ELDK v4.2 uses:

 ppc_6xx-gcc (GCC) 4.2.2

and 
 GLIBC v2.6

But I measured the same latencies with ELDK v4.1:

 ppc_6xx-gcc (GCC) 4.0.0 (DENX ELDK 4.1 4.0.0)

 GLIBC v2.3.5

Wolfgang.

--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" 
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html