Re: [patch] Real-Time Preemption, -RT-2.6.11-rc3-V0.7.38-01

From: Steven Rostedt
Date: Tue Mar 15 2005 - 08:08:57 EST

On Tue, 15 Mar 2005, Ingo Molnar wrote:

> * Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
> > I've realized that my previous patch had too many problems with the
> > way the journaling system works. So I went back to my first approach
> > but added the journal_head lock as one global lock to keep the buffer
> > head size smaller. I only added the state lock to the buffer head.
> > I've tested this for some time now, and it works well (for the test at
> > least). I'll recompile it with PREEMPT_DESKTOP to see if that works
> > too.
> good progress - but the global lock may be a scalability worry on
> upstream though. Would it be possible to just mirror much of the current
> lock logic, but with spinlocks instead of bitlocks? And there should be
> no #ifdefs on PREEMPT_RT.

The first patch I had just converted the bit spinlocks to spinlocks but I
thought that adding two spinlocks was too much for every buffer head, even
if it wasn't in the ext3 file system. The journal head spinlock is just
used to add and remove the journal heads from the buffer heads, so I'm not
sure how much contention is on them. I only have a dual smp system, so I
can't test the system on large number of CPUs. What do you think, should
we sacrafice memory for speed?

What should we use instead of #ifdef PREEMPT_RT? Or should we just keep it
the same for both. Since this fix is only to fix spinlocks that schedule,
I figured that it would be better not to waste the memory of those not
using PREEMPT_RT. Should I use the opposite PREEMPT_DESKTOP?


-- Steve

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at