[PATCH RT 3/3 - take two ] fix get_monotonic_cycles for latency tracer

[Added comment about not being able to take the xtime lock in get_monotonic_cycles - suggested by John Stultz] The latency tracer on SMP was given crazy results. It was found that the get_monotonic_cycles that it uses was not returning a monotonic counter. The cause of this was that clock->cycl

Re: [PATCH RT 3/3] fix get_monotonic_cycles for latency tracer

-- On Fri, 24 Aug 2007, john stultz wrote: > > > > - /* calculate the delta since the last update_wall_time: */ > > - cycle_delta = (cycle_now - clock->cycle_last) & clock->mask; > > + } while (cycle_raw != clock->cycle_raw || > > +cycle_last != clock->cycle_last); > > So if I'

Re: [PATCH RT 3/3] fix get_monotonic_cycles for latency tracer

On Fri, 2007-08-24 at 13:57 -0400, Steven Rostedt wrote: > The latency tracer on SMP was given crazy results. It was found that the > get_monotonic_cycles that it uses was not returning a monotonic counter. > The cause of this was that clock->cycles_raw and clock->cycles_last can > be updated on an

[PATCH RT 2/3] initialize the clock source to jiffies clock.

The latency tracer can call clocksource_read very early in bootup and before the clock source variable has been initialized. This results in a crash at boot up (even before earlyprintk is initialized). Since the clock->read variable is points to NULL. This patch simply initializes the clock to use

[PATCH RT 3/3] fix get_monotonic_cycles for latency tracer

The latency tracer on SMP was given crazy results. It was found that the get_monotonic_cycles that it uses was not returning a monotonic counter. The cause of this was that clock->cycles_raw and clock->cycles_last can be updated on another CPU and make the cycles_now variable out-of-date. So the de

[PATCH RT 1/3] time keeping add cycle_raw for actual incrementation

The get_monotonic_cycles needs to produce a monotonic counter as output. Currently it uses cycles_last as the base to add the delta too. cycles_last only is the counter that was last measured and is cyclic in nature (not monotonic). This patch adds a cycle_raw to produce an accumulative counter. U

Re: [PATCH RFC] Priority boosting for preemptible RCU

On Fri, Aug 24, 2007 at 01:51:21PM +0530, Gautham R Shenoy wrote: > On Thu, Aug 23, 2007 at 08:55:26AM -0700, Paul E. McKenney wrote: > > > Even if we use another cpumask_t, whenever a cpu goes down or comes up, > > > that will be reflected in this map, no? So what's the additional > > > advantage

Re: [PATCH RFC] Priority boosting for preemptible RCU

Andrew Morton wrote: >> +for_each_possible_cpu(cpu) { >> +rbdp = per_cpu(rcu_boost_dat, cpu); >> +for (i = 0; i < RCU_BOOST_ELEMENTS; i++) { >> +rbdp[i].rbs_mutex = SPIN_LOCK_UNLOCKED; > > Doesn't this confound lockdep? We're supposed to use spin_

[PATCH RT] - Mellanox IB driver patch

Hi Ingo, RT driver patch to eliminate in_atomic stack dump. The problem code was identified by Michael S. Tsirkin, and he suggested the fix. I adapted to use RT's _nort primitives- should work correctly in all configs. Thanks, Sven Fixes in_atomic stack-dump, when Mellanox module is loaded

Re: [PATCH RT] - rebalance_domains incorrect parameter

* Sven-Thorsten Dietrich <[EMAIL PROTECTED]> wrote: > Same issue has been fixed in mainline by: > > diff-tree de0cf899bbf06b6f64a5dce9c59d74c41b6b4232 (from > 5d2b3d3695a841231b65b55 > Author: Oleg Nesterov <[EMAIL PROTECTED]> > Date: Sun Aug 12 18:08:19 2007 +0200 > signed-off-by: Sven-Thor

[PATCH RT] - rebalance_domains incorrect parameter

Hi Ingo, the RT patches for .22 and .23 are passing an incorrect parameter to rebalance_domains. I had this queued up for a few days - its still wrong in .22 and .23 RT patches. Same issue has been fixed in mainline by: diff-tree de0cf899bbf06b6f64a5dce9c59d74c41b6b4232 (from 5d2b3d3695a84123

Re: [PATCH RT] - trivial branch in scheduler.

* Sven-Thorsten Dietrich <[EMAIL PROTECTED]> wrote: > > Hi Ingo, > > the trivial code is in various RT patches as well as in 2.6.23-rc git's > scheduler. > > Thanks > > Sven > > Remove trivial conditional branch in Linux RT CFS > scheduler's can_migrate_task function. > > signed-off-by: Sv

[PATCH RT] - trivial branch in scheduler.

Hi Ingo, the trivial code is in various RT patches as well as in 2.6.23-rc git's scheduler. Thanks Sven Remove trivial conditional branch in Linux RT CFS scheduler's can_migrate_task function. signed-off-by: Sven-Thorsten Dietrich <[EMAIL PROTECTED]> Index: linux-2.6.22/kernel/sched.c =

Re: [PATCH RFC] Priority boosting for preemptible RCU

On Thu, Aug 23, 2007 at 08:55:26AM -0700, Paul E. McKenney wrote: > > Even if we use another cpumask_t, whenever a cpu goes down or comes up, > > that will be reflected in this map, no? So what's the additional > > advantage of using it? > > The additional map allows the code to use something othe