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

[Ingo Molnar]

* Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:

> > 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?

there are two bad effects of global spinlocks: 1) contention 2)
cacheline bouncing. It's #2 that would affect this spinlock. While i'm
not sure this would show up in usual benchmarks, we should rather err on
the side of more scalability. Two spinlocks are just two more machine
words on most architectures, so i dont think it matters all that much,
while it removes a major wart - as long as the two extra locks are for
ext3 buffer-heads only.

> 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?

i'd go for removing bit-spinlocks altogether, in the upstream kernel. It
would simplify things, besides making PREEMPT_RT simpler as well. The
memory overhead is not a big issue i believe. (8 more bytes per ext3 bh,
on x86)

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/