[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4875BF57.8030405@grandegger.com>
Date: Thu, 10 Jul 2008 09:50:47 +0200
From: Wolfgang Grandegger <wg@...ndegger.com>
To: Wolfgang Grandegger <wg@...ndegger.com>,
Luotao Fu <l.fu@...gutronix.de>,
Steven Rostedt <rostedt@...dmis.org>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
LKML <linux-kernel@...r.kernel.org>,
RT <linux-rt-users@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: 2.6.24-rc8-rt1: Strange latencies on mpc5200 powerpc - RCU issue?
Luotao Fu wrote:
> Hi Wolfgang,
> On Wed, Jul 09, 2008 at 03:15:01PM +0200, Wolfgang Grandegger wrote:
>> Hi Fu (without n)
>>
> ....
>> 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).
> 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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists